Prev | Current Page 329 | Next

L. McColl-Sylvester and F. Ponticelli

"Professional haXe and Neko"

Another good aspect of having tests is that they provide real examples for
the developers that want to use the tested library; the code in the tests is easy to read because it is short
for its own nature and provides a sort of living document. A positive side effect is that a developer used
to writing tests is more concerned in writing code that has less dependencies and is more isolated from
the context: this is because testing classes with a lot of dependencies can be a real pain.
The Unit Testing concept is not bound specifically to a technical implementation and potentially a Unit
Test could also be a set of instructions manually written on a piece of paper; what renders the tests really
effective is when they are aggregated in an automated context. The tests are aggregated in a processing
unit that in one go executes all of them, reporting the number of tests run and in this case the number of
171
Chapter 6: Organizing Your Code
tests that have failed and their names. The automatic process is repeated many times during the
development to help spot bugs and this is the reason why tests are often optimized for performance.


Pages:
317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341