Test-driven development (TDD) is a software development process that relies on the repetition of a very short development cycle: first the developer writes an (initially failing) automated test case that defines a desired improvement or new function, then produces the minimum amount of code to pass that test, and finally refactors the new code to acceptable standards.
The following sequence of steps is generally followed:
- Add a test
- Run all tests and see if the new one fails
- Write some code
- Run tests
- Refactor code
There’s a plenty of articles written on TDD and Wikipedia is always a good start. This article will focus on the actual test and implementation using variation of one of the Roy Osherove Katas. Do not click the link until you’re finished with this article. This excercise is best done when not all requirements are known in advance.
Below you will find the test code related to each requirement and afterwards the actual implementation. Try to read only one requirement, write the tests and the implementation yourself and compare it with the results from this article. Remember that there are many different ways to write tests and implementation. This article is only one out of many possible solutions.
If you are still working in a waterfall methodology, you should know that the world is moving towards new methodologies… some famous concepts would be Agile, XP or Scrum and surely those words will sound familiar to you especially during the recent years.
Especially in the case of scrum, the first scrum team in which Jeff Sutherland participated took place in 1993, literally 20 years ago, and now it’s mature enough to be taken by big companies.
When moving from the traditional waterfall process with manual testing towards BDD with automated execution of scenarios, one of the often asked questions is “how do you measure your test coverage?”. What it really wants to say is “we have high test coverage with manual testing, can you guarantee the same or more with the BDD?”. From there on usually comes the suggestion to transfer one-to-one manual tests to the BDD format. That’s not a good idea since the result would be less than adequate transformation to the different format without any tangible change. BDD is not only about automation but about the way we construct and deliver software.
Code Coverage Analysis
Main usages of code coverage analysis is to:
- Find areas of software under test that were not exercised by a set of test cases.
- Help in creation of additional test cases to increase the coverage.
- Provide quantitative measure of test coverage as indirect measure of quality.
- Identify redundant test cases that do not increase coverage
- Identify parts of the code that is not in use
Since years, many software companies have their Quality department, which in many cases implies that they have the responsibility to assess the quality of the releases. This department is typically called QA department (standing for Quality Assurance), but I rather think that they are doing much more of checking releases than to assure the quality and I see a huge difference these two concepts, that is, between a QA engineer and a QC engineer:
- QA stands for Quality Assurance, therefore an engineer that ensures the quality. Every time a new release is being built, the QA engineer ensures that the quality is built in it. The QA is responsible for improving the processes and participates actively in the creation of the testing tools.
- QC stands for Quality Checking or Quality Control. This engineer typically waits for the release to be finished in order to check if the quality is built there. A Quality Checker typically creates a list of test cases based on the requirements themselves and puts them in a tool to plan each of the BTCs. Later he executes all the test cases, in most cases manually and tracks their execution.
Testing shows the presence, not the absence of bugs. Edsger W. Dijkstra
Two common types of testing are black-box and white-box testing. Both can drive or be driven by development.
Black-box testing (also known as functional testing) treats software under test as a black-box without knowing its internals. Tests are using software interfaces and trying to ensure that they work as expected. As long as functionality of interfaces remains unchanged, tests should pass even if internals are changed. Tester is aware of what the program should do but does not have the knowledge of how it does it. Black-box testing is most commonly used type of testing in traditional organizations that have testers as a separate department, especially when they are not proficient in coding and have difficulties to understand the code. It provides external perspective of the software under test.