Some solutions‎ > ‎testing‎ > ‎


Tags: tdd_tag, testing_tag, junit_tag

// TBD

 What is software process and quality assurance. 
  • Before writing a line of production code, you first build an automated-failing test, which motivates this code.
  • You write only as much production code as required for the test to arrive at working code as fast as you can.
  • As soon as the code works, you refactor it in order to make it as clean as possible, which basically means to remove all duplication.
  • The development progresses in small steps, where testing and coding alternate. Such a "micro-iteration" does not take more than 10 minutes.
  • When you integrate production code into the overall system, all unit tests have to run successfully.

TDD benefits (from Unit Testing in Java: How Tests Drive the Code):
  • Each single piece of code gets tested. This means changes that could destroy existing functionality are discovered immediately. It plays a decisive role, particularly at the time of software integration, and thus serves as a form of continuous regression testing.
  • The tests document the code because, in the ideal case, they show both the normal use and the expected reaction in case of errors.
  • The micro-iterations are very short, which means very quick feedback. Within 10 minutes at most, you cannot program a lot, so you cannot make many mistakes.
  • The design of a program is essentially determined by the tests. In many cases, this leads to simpler design as compared to one devised on the drawing board, because it is hard to write simple tests for complex structures. This is the reason why many consider test-driven development to be much more of a design approach than a testing approach

What we can actually test:
  • single methods
  • the protocol of a class
  • the interaction between two or more objects
Factors that play a role in determining the optimal testing effort:
  • Complete testing with the declared intention to verify the correctness of a program is impossible to achieve for all nontrivial programs. The objective of our testing efforts; therefore, can only be to find as many faults as possible at a manageable effort level.
  • There is an acceptable error level for each system. The actual error level achieved by an implementation is usually hard to predict without running the application productively for some time.
  • The effort required to achieve a specific error level grows in a nonlinear way with regard to the benefit. For this reason, we can achieve an average error level at a relatively small testing effort.
  • If possible, testing should concentrate on finding the severe bugs.
  • The correct number of unit tests has positive effects on the development velocity, as soon as the project term exceeds a certain duration.
  • Test-first development requires at least a sufficient number of tests so that all developers will have enough confidence in their own work. When a developer is forced to fall below his or her personal minimum quality standard, due to time pressure for instance, then identification with the result of their work and their motivation and productivity will suffer.
  • Unit tests are not only a quality-assurance technique. Above all, they steer the development of our evolutionary design.
  • Unit tests are not the only tests we use, so they don't have to fully guarantee the desired error level.
  • Too few tests hold another danger: we get lulled into a false sense of security.
Test must be written before solving this issue.