Condition Checking Inside Code

Many code blocks has condition checks during execution. If the check is nested deep inside some class structure, it is not easy to determine which containing class the check belongs to. Consider the possibility of shifting the checking outside execution, such as a pre-condition check during system initialization, or so on.

Consider the following.

bool Controller::execute(char* data_) {
    if(data_==NULL) {
        return false ;
    }
    if(_manager==NULL) {
        return false ;
    }
    Object* obj = _manager->getObject(data_) ;
    obj->process(data_) ;
    return true ;
}

There are two checks. The check if(_manager==NULL) can be placed outside the method since _manager is independent of the execution and should be set beforehand anyway.

Test Visualization

A typical system has a huge (I mean huge) number of test cases. How do we know if the test cases sufficiently span our system? We need to have a way to visualize tests. One simple way is to start with a domain model of the system and start to identify the objects and variables and relationships.

The better the tester, the more unlikely developers will test

I have been working with an organization, which does very little or no-code level unit testing. All test automation are conducted using blackbox tools by testers. They even build custom tools to do these. But as these test tools and test scripts get mature, the developers have lesser impetous to do their own testing. The most cited reason is that it duplicates blackbox testing.

Of course, everyone knows that white box (code-level) tests execute faster and can execute within a debugger and hence easier to isolate faults. They have also the potential of greater coverage.

Unfortunately, there is a barrier to get started, and the the starting point usuallyseem so similar to duplicating black-box tests even though it isn't.

Then it dawn upon me - that the developers ar just spoilt. Since someone else is doing the testing, why duplicate it? Worse still the blackbox test scripts are in a different language than code. This splits the role between developers and testers even further.

Moving Again

I am moving my blog again.