Coding, Testing: Which is First?

I saw some managers planning that Resource-A will do the coding and Resource-B will do the Unit testing. In my opinion it is totally a misconception about the unit testing. Unit testing is not a task to complete. It is integral part of coding. Unit testing without coding and coding without unit testing both are not productive. In a test driven environment, we need to design and plan our work so that after coding few lines, write test cases and verify the code just we completed.

I noticed some people coding and directly testing from UI. In this approach unit tests gets lower priority in front of the anxiety to do the final testing using UI. Unit tests just considered as a distraction and additional work. This leads to a poor quality of code. More time spent on debugging during development and testing. Writing unit tests after coding increases development time and there is a more tendency that not able to cover all important cases. Again it leads to a poor quality of code. Bottom line is, if we don’t do it in a right way, adding more time can not improve the quality.

It is important to understand the reasons for the below questions
Why people tend to do the integration testing before unit testing?
How it matters unit testing after complete coding instead of testing while coding?

Some times people not sure about what they are coding and not sure weather it is going to work together with the rest of the system or not. So they will focus directly on integration testing. This is true because at the end if they find this solution is not going to work, it need to throw out all the code along with the unit tests. Instead of trying to do the coding work it is required to do some design home work. Some times adding an integration test with the stubs and discussing with the peers about the solution helps to improve the situation.

My answer to the second question is it definitely matters the way we write the unit tests. We can apply a generic principle, If the delay in getting feedback increased, its effectiveness will be decreased. I mean executing unit tests is something like getting feedback from the code. We can write good tests cases for the code written in few minutes compared to the code written in last week or last month. Also it takes more time to recollect and understand the code. Taking immediate feedback saves time in debugging during integration.

Code Coverage - Tool or Goal?

Code coverage can not be a goal for any software development process. It just helps as a tool for developers and management.

While using code coverage by managers it is important to note that more code coverage does not give any guarantee about the correctness of the system. It can not be used as an objective for the team. It may drive the development team towards the wrong direction of getting code coverage. Coverage driven development is very dangerous because it may happen that developers just focused on the silly branching scenarios instead of thinking from the use case and test scenario point of view. Management can use the code coverage information to get a feel of how much more testing required.

Developers also not expected to consider code coverage as a goal. In a test driven development, we need to focus on different scenarios and write the test cases. We can use code coverage information to discover the missing test cases. Some times we expect a particular portion of the code already covered but code coverage shows a gap. This indicates our test is not doing as we expected. Code coverage information helps to find the bugs in test code.

In development process, do the coding and developing cycles until we get satisfied with required functionality. At the end take coverage report and analyze the effectiveness of the tests. We may get some hints about the missing test cases. It is not important to cover every branch of the condition, just for coverage purpose. Add more tests only if it makes sense.

Test Driven Development is driven by tests and tests are driven by use cases and requirements. In this development process code coverage is a tool to get the correct test cases. If we focus on code coverage, development time increases without getting any quality benefit. If we focus on test cases, quality of the software increases and we will get code coverage as by product.

Escaping Readability?

In most of the programming languages to assign special characters as a string, we need to escape them using backslash. It is not an issue at all for most of the times. Even though we are habituated, I like to highlight the difficulties with this escaping from my experience.

There is a chance of making mistake while escaping, may lead to incorrect results. Some times we get compilation problem but some times it escapes the backslash following character incorrectly. For example, if we forgot to escape “c:\backup”, it will treat “\b” as a back space character.

Due to escaping we will loose the readability of the string. More specifically we will face this problem while dealing with regular expressions because they also require escaping. Let us say if we want to use \ as a character in regular expression, we need to escape it as “\\”. While writing this expression in Java code every slash need to be escaped. Then this regular expression becomes “\\\\”. Otherwise both regular expression compiler and Java compiler can not interpret correctly. If we write a big regular expression with special characters it is very hard to interpret the actual expression.

Even though these problems we face rarely, while dealing with them causes a lot of inconvenience. In language it self we may add the capability to escape automatically using some special syntax. It is difficult to change the language syntax so no need to discuss much about the language changes. But it is easy to provide some kind of view transformations from the editors. When we place the cursor near to a string with quotes, an info bubble comes up which shows the string without escaping formalities and allows editing also. Once we click outside it looks like a normal string with escaping. It is just a basic thought for the solution but there may be better ways to address this problem.