One of the best descriptions of the hierarchy of tests that I have seen comes from “Growing Object-Oriented Software, Guided by Tests” by Steve Freeman and Nat Price.
1. Acceptance Tests: Does the whole system work?
2. Integration Tests: Does our code work against code we can’t change?
3. Unit Tests: Do our objects do the right thing, are they convenient to work with?
Can we now get on with some work, rather than discussing definitions ad nauseam?
Tags: acceptance, definition, integration, testing, unit
Mar 7
Posted by Tom in Soap Box, Software Development | 3 Comments
I’ve been saving this rant for a while now:
1. Test everything at the front-end, in exquisite detail – every project sponsor understands what tooltip 0 really means. Also a great idea if you like long-running and fragile tests that require deployments, browsers, testing frameworks and the kitchen sink. Testing at different layers, and perhaps even without a browser or (in java) a servlet container is for the weak.
2. Perform a database cleanup before and after every test, whether it needs to be done or not. For the truly adventurous add something about clearing out JMS queues and stopping scheduled tasks while you are running the cleanup tasks.
3. Always use the same data for tests, and better still use the same data for different tests. That way you will have do perform anti-pattern 2 with no questions asked. If anyone does ask about random or unique data just scoff sagely.
4. For those tied to java, run each test in its own JVM. If you happen to use a DI framework with lots of XML make sure it is initialised completely for each test. If anyone mentions forkmode=once just pretend to ignore them until they go away.
5. Write your application so that you need a JavaScript enabled browser before you can test anything at all. Progressive enhancement is only for those who cannot see.
Catharsis.
Tags: anti-pattern, browser, cleanup, Java, javascript, testing
A year ago I wrote a post about about writing a program to performance test web applications (see Thumper). Since I finished off the original set of python scripts, I haven’t really had the time to continue developing this application further in either Java, Ruby or any other language. Fortunately there is someone out there who thinks that threaded performance tools have an inherent flaw. Enter JCrawler … go out and try it.
Arclite theme by digitalnature | powered by WordPress