This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
How many people use stock JUnit, and how many people have their own local extensions? We have a few, the absolute favorite being a method canRun() in our own TestCase subclass, and a run() method that calls it to decide whether to skip certain tests on certain platforms. I wrote this up in the Journal a while back.
Anyway, I know I could answer this by looking at the book's web site, but does "JUnit Recipes" talk about writing JUnit extensions at all?
JUnit Recipes does not provide much about specifically how to extend JUnit. I rarely find it necessary to do so for my testing: I tend just to use the existing test runners and all the prefab extensions (HtmlUnit, XMLUnit, Cactus, ...).
Many of the questions we get on the JUnit Yahoo! group garner suggestions for writing custom test runners, but rarely do we get a question that leads us to consider extending the framework itself.
I consider JUnit's framework to be adequate for my needs, but then, perhaps I'm just not solving hard enough problems.
Author of <a href="http://www.amazon.com/exec/obidos/ASIN/1932394230/ref=jranch-20" target="_blank" rel="nofollow">JUnit Recipes: Practical Methods for Programmer Testing</a>
Originally posted by Ernest Friedman-Hill: How many people use stock JUnit, and how many people have their own local extensions?
The only "local extensions" I remember using are project specific assert methods...
... a method canRun() in our own TestCase subclass, and a run() method that calls it to decide whether to skip certain tests on certain platforms. I wrote this up in the Journal a while back.
Well, recipe "4.6 Separate the different kinds of test suites" might be interesting to you...
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Ernest, We have several types of minor extensions: - project specific asserions - general assertions (for collections and other data structures) - use of test collector to collects tests by package using reflection - section 508 test (plugs into each application to test for section 508 compliance)
Yes, section 508 is an accessibility law. All applications developed for the federal government are required to meet the 16 provisions. The Department of Health & Human Services has a chart that lists the provisions in a clear way.
There are many free tools that let you run your generated HTML through and highlight your Section 508 violations. But it is quite tedious to do this for every single JSP (and every single display combination for those JSPs) on a regular basis. It is also quite tedious to look at the results of these tools. After a couple of experiences with 508 violations slipping through after we "implemented Section 508", it was time to do something about it. Enter Junit - great for tedious, repeatable activities.
Many of the 508 practices are very programatic. For example, practice a states you must have an alt tag for every image. It's very easy to go through a JSP and check for that. We also check for form labels, table headers/summaries and a couple other things. We check for html and struts tags. Granted junit can't check for everything, but some of the 508 practices (like background colors) need to be checked by hand even after using the 508 tools anyway.
Our Section 508 test class is an abstract junit test case (extends TestCase) that provides tests for some of the provisions. It resides in a library jar with our other common stuff. Each application subclasses this test case and implements the method where we state the web project name. After that, the 508 test loops through the jsp directories and gathers them all. It then uses JBs parameterized test case pattern to run each test for each jsp and report the results as separate tests.
Our Section 508 flags a violation about once a week during heavy development. We run it with our other Junit tests, so it gets run often. So it's definitely keeping our code compliant.
Well this was long. I hope I didn't give you guys too much detail.
author & internet detective
I find that the base Junit provides enough functionality to do the base testing. I have used some of the Junit extentions such as Cactus, and Struts Test Case. Both of these are great for testing Struts Actions, and servlets.