In the software development life-cycle, everyone owns quality. Ideally, developers start ensuring quality early in the development cycle with testing tools like Junit and TestNG, and QA teams follow up with functional system tests at the end of the cycle, using tools like Selenium. But even with excellent quality assurance, some applications are deemed low-quality upon delivery. Why? Because they don't do what they were intended to do.
One of the features of Framework for Integrated Tests (FIT) is that it enables the customer or business side of an organization to get involved in the testing process early (i.e., during development), whereas JUnit's strength lies in unit testing during the coding process. This article by Andrew Glover shows you how to combine the best of FIT and JUnit for better teamwork and effective end-to-end testing.
- Posted by: Frank Charles
- Posted on: March 13 2006 16:46 EST
- Another Good Article is the OCI Java News Brief by John Shuster on March 14 2006 11:02 EST
- Wiki based .... by Jyothi Bacche on March 15 2006 06:09 EST
- Better code testing with JUnit and FIT by Ivan Belis on March 15 2006 06:42 EST
Another good article on the topic of FIT is published as a Java News Brief to the Object Computing Web site. You can see it here:
I would also look at this,
- Wiki based test server on top of "FIT"
Maybe i am over-simplifying things but is this not just data-driven unit testing ?
A test scenario is run with information from an external file. This can also be achieved with a data-driven unit test.
The framework does provide a consistent manner of representing the external test data. That surely a good point, but that alone does not convince me.
Altough it would be nice, i don't think the business is going to maintain the test-data, in the best case they supply some initial examples.
Are there some real-life examples of FIT tables ?
We use FIT in our organisation and it seems to do the job. Integrates into our build and the output is quite easily to read.
Setting it up can be a bit fiddly at times, but it seems to serve its purpose. But you are correct, mostly it is developers that keep the FIT tests up-to-date, although it has also been quite useful for our testers to update tests without touching any code.
I remember briefly reading about another tool, DDSTps not too long ago (http://www.theserverside.com/news/thread.tss?thread_id=38951) which conceptually seemed simple enough. Perhaps even better since you don't need to play around with HTML markup.
DDSteps (ddsteps.org) has chosen a different approach to separating test structure, test code and test data test from each other (yes - there are three dimensions!).
1) Test Structure - functional tests are split into reusable parts: test STEPs (second part of the name). A functional test case is then a sequence of such steps. Test Designers work with these blocks. They have parameters to make them reusable.
2) Test Code - written in Java using JUnit and other tools such as JWebUnit. Add-ons available for JUnit are everywhere. Best bang-for-the-buck! Programmers implement the test steps and test cases and keep them in the version control with the code.
3) Test Data - written in spreadsheets. Excel rocks, which FITnesse has discovered too, offering import/export. For DDSteps it's "native". Also kept in the version control system.
DDSteps is useful from the unit test level (just plain test data management) up to the end-to-end functional level. It scales because it is able to modularise the test code and test data.
And most importantly - tests are versioned with the code. If you go back to do a patch, the tests can be run against that code. If the tests are "outside" the code base, there may be tests for functionality that was not in the older version. Why bother with keeping two systems in sync?
I do acknowledge that FIT(nesse) has a web GUI that may suit many non-technical users. We just did not have any such users when we built DDSteps :-)
DDSteps Lead, www.ddsteps.org
Senior Java EE Consultant, www.jayway.se
We are in the early stages of rolling out FIT at our company, and we are versioning the tests with the code as well. The FIT tests have a huge value as communication tools above and beyond their automated test value.