testdriven.com Wrangling quality out of chaos

Jeffrey Fredrick gives a simple example of how Agitator is driving the refactoring process.
link

Craig Walls writes: "I’ve caught the unit-testing bug and am immersing myself into everything I can find about it. I’ve been able to find plenty of stuff on how to test practically everything under the sun, except for one thing: Hibernate mapping files."
link

Vincent Massol writes:

"Applying a working build strategy for testing against a database is not easy. It depends on the complexity of the database model, it depends on the size of the teams. However, I’ve found that the strategy described below is the one that has worked the best for the projects I have been involved in."
link

Darrell Norton discusses the pros and cons of four different ways to set up NUnit tests in Visual Studio.NET:
- In the same class
- In a separate class, same project
- All tests in 1 separate project
- All tests for a project in a separate project
link

A dynamic proxy dynamically generates a class at runtime that conforms to a particular interface, proxying all invocations to a single ‘generic’ method. Joe Walnes describes such a dynamic proxy in .NET.

link

Paxson Yang describes how he improved the log4j logging mechanism, by plugging some of XMLUnit’s functionality into a Java test case, thereby preventing a lot of DOM API calls.
link

"Writing unit tests for code relying on container services is a problem, but usually it’s relatively easy to overcome that by mocking up the troublesome interfaces. However, sometimes you’re forced to use an API which just doesn’t want to have anything to do with unit testing. The InitialContext is one of those."
– Lasse Koskela
link

"The main reason for the recent upsurge in homebrew automation is XP. The majority of the open-source testing tools available today have been built by test-infected programmers. XP is based on tight iterations and constant code refactoring. This makes automated tests a requirement. Automated unit tests do part of the work, but automated system acceptance tests are also needed. This has motivated talented test-infected developers to figure out ways to automate acceptance tests for their software products. The results are fascinating. Indeed, i think they are the most important thing happening in the world of automated testing. I’ve been spending most of my research time over the past year or two learning from this community."
– Bret Pettichord
link

The bugs that are found in [TDD projects] are often tricky, time consuming and difficult to replicate. Nailing down the cause of these bugs often requires testers and developers pair testing. These bugs are not only hard to find, they are often difficult to fix, and seem to be resistant to the development efforts which are so successful in catching many bugs during the coding process. I’ve started calling these bugs "superbugs".
– Jonathan Kohl
link

Suppose you have a set of tests, A through Z. Suppose you had N teams and had each team implement code that passed the tests, one at a time, but each team received the tests in a different order. How different would the final implementations be? Would some orders lead to less backtracking?

I decided to try a small version of such an experiment at the Master of Fine Arts in Software trial run. Over Christmas vacation, I collaborated with my wife to create five files of FIT tests that begin to describe a veterinary clinic. [..] I implemented each file’s worth of tests before we created the next file.

Author: Brian Marick
Published: January 29, 2004
link

A little trick to make JUnit display test results in a way similar to AgileDox, overriding TestCase.getName().

link

"I see two fundamentally different types of testing in an XP/TDD/Agile project. Acceptance testing and Unit testing. There’s no point in describing acceptance tests as driving the design but unit testing is commonly viewed as doing just that." — Jon Tirsen
link

Is it better to create your own mocks with the IDE or use one of the dynamic mock packages, such as JMock?
link

Jon Tirsen discusses the CacheInterceptorTest in Nanning. It outlines a simple recipe for testing interceptors.
link

Intercept’s mixin support is completely orthogonal to the interceptor support, making it convenient for passing information down interceptor stacks.
link

In a web application, how do you unit test an MVC action? The solution that I’ve adopted is to use mock objects. I want to be able to run my unit tests quickly and without the hassle of setting up a web/application server environment and deploying my code into it.

Weblog: Simon Brown
link

JUnit essentially does a lot of things to make life a bit easier. For starters, uses reflection to create instances of the test case for each testXYZ method, with the test method being the name of the test. The test name is then used by the default runTest() implementation to invoke the test method. By overriding the runTest() method, I removed a lot of the smarts, but at least I’ve got less typing.
link

The problem with some codebases is that many of the "mocks" replace the wrong classes. The result of this is overly complicated tests, in addition to a false perception of what is being tested. Many of the "mocks" in this codebase are not really proper mocks, apart from having the word "Mock" in their name.

Blogger: Aslak Hellesoy
link

Jon Udell’s blog

link

Mike’s excellent account of teaching his "Test-Driven Development With JUnit" tutorial is a must read.

link