5.3 Project-Specific Expansions


5.3 Project-Specific Expansions

Many projects have particularities that also have an impact on testing. In the simplest case, an additional or modified assert variant is needed, for example, to compare files. In difficult cases, the test results should be logged in XML. And then, there is this project that has to run the same test with hundred different records.

Go ahead, expand JUnit with your own test functionality. [4] Or better yet, have a look around for expansions readily available (see also Appendix A, Section A.2, JUnit Expansions), and don't hesitate to hit your keyboard in case the wheel hasn't been invented yet. Oh, and finally, don't forget to make your expansion available to other JUnit users at some point in time. We will see a few small and a few larger expansions in the further course of this book.

Note that building a test framework should not turn into an end in itself, but rather facilitate and support our test effort. Any framework handicraft beyond this scope is useless for the progress of the project and amounts to nothing more than killing after work hours.

[4]But think it over 10 times before you change the JUnit source code itself. Each new version will entail changes and here we are, caught up in a time-consuming and unnecessary maintenance spiral.




Unit Testing in Java. How Tests Drive the Code
Unit Testing in Java: How Tests Drive the Code (The Morgan Kaufmann Series in Software Engineering and Programming)
ISBN: 1558608680
EAN: 2147483647
Year: 2003
Pages: 144
Authors: Johannes Link

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net