J2EE patterns: Externalizing the Test Data and Test Case from JUnit test suite

  1. Externalizing the test cases and test data which test cases are referencing from test suite(s) is very critical in junit based automated test frameworks. This can be easily achieved by externalising the test data in the form of java.util.Properties object and test cases in the form structured xml files. Test case specific characteristic such as 'executation_order', 'no_of_cases', 'canExecute' etc can be easily configured under test_case.xml. These configuration files can be easily wrapped in the form of Singletons and offered as services under Base junit test case.
  2. Sorry, but this is a quite dangerous anti-pattern. Unit-tests are not simply for testing a piece of code. They carry several, additional, very important roles. One of them is - documentation.

    In a well-tested code, unit-tests are the first examples of API usage (API that they test). A TDD-experienced developer can learn a lot about the API, looking at its unit-tests. For the readability and clarity of what unit-test tests, it is very important that test data is in the code and the reader does not have to consistently hop from a configuration file to the test code.

    Also, usually boundary conditions for a code (which is what test data commonly is) almost never change, so there is more harm in this "pattern" than gain, indeed.

  3. I think that if you are testing basic operations such as
    cruds you can externalize your data on spring xml files
    for example and have it injeted on your tests.

    With this you can get a complete crud test with dao
    with one class with just 5 files. I've done this and
    I like this.

    Do you find that even basic crud test should be all
    writen in java files?

  4. What's in a name?[ Go to top ]

    I agree 100% that unit tests shouldn't externalize data - they should be documentation for the next developer to maintain the product.

    That being said JUnit is an excellent, general purpose, driver/engine/thingy that has nearly universal support from IDE makers, build engines, and reporting engines.

    So what to do if we want to create Enterprise Application Integration tests? Enterprise integration is centered around document orientation and large data sets (i.e. much more about the data than the code). Consider ThoughtWorks article on EAI testing. ThoughtWorks doesn't prescribe an implementation but I would rather not reinvent the wheel here - driving JUnit test cases from data is a pragmatic solution, IMO.
  5. Irakli,

    I posted a comment to your comment in the "Cross Domain Cookie Provider" thread. Can you look at my question and comment. Sorry to take this channel, but it was the only obvious way that I could see to get a message to you (as you seem to be active in this thread currently).


    Bob Brandt
  6. I'd have to agree that this is dangerous. However, if one leaves some default data, dependency on external files will be less necessitated and there will be some retained example data as "documentation". I do like the idea of having an external set of data that one can edit without touching compiled code.