The biggest benefit when implementing Fit testing is sharing some of the responsibility of test driven development with “the business”. With Fit testing, BAs and Project Managers can write tests without having to know a programming language - they can write the tests in an HTML Editor or Word. We still write unit tests with Junit, MockObjects, StrutsTestCase, etc., but the tests are augmented with functional tests using Fit. I recommend it.
For more information on Fit Testing in Java, I’ve put together a tutorial at code.supergloo.com: Example of Fit Testing in Java
We are doing some performance tuning and load testing with JProbe and The Grinder this week. Thank you to developers of both of these tools.
Our production environment consists of numerous 2 GB RAM, dual-CPU Linux boxes running Orion Application Server, Spring Framework, Hibernate, etc. We run The Grinder from a Windows boxes. Although JProbe does not officially support Orion, it was a breeze to setup.
Have you ever been in a development environment where technical direction is implemented by “gut” feeling? You know, maybe a shaman like developer whom everyone follows because their vision of performance or debugging is “usually” correct. Or, have you ever been on a development team where people ooh-and-ahh over a developer’s supposed skills because they speak with much confidence. You know, with tools like The Grinder and JProbe, gut feelings and various personalities can be removed the equation and actual insight into application performance under load can be acquired.
For example, this week there was all kinds of speculation on what parts of the application was the resource hog. Here’s another common scenario - the app ran fine under no load, but problems arose after stress testing. Anyhow, after using The Grinder with JProbe, turns out we were all wrong. We found a few resource hogs and we will be able to resolve.
Now, if we can somehow arrange a cage match between shaman guy and confidence guy, we’ll be all set.
