Responsibility driven design is an approach that helps you shift focus from object state to interactions and responsibilities. This article shows how test driven development with mock objects facilitates responsibility driven design and drives you towards a more cohesive, loosely coupled design. Examples in Java.

This article will explore a few ways to get the most out of your PHPUnit tests.

Google provides an interesting and easy-to-use open source alternative for developing unit tests to validate C/C++ based software. This article introduces readers to some of the more useful features of the Google C++ Testing Framework and is based on version 1.4 of the release

This article shows how the behavior driven development can be applied to database development and how it can be used to develop and design databases in an iterative and incremental way.

Rather than preach on about the virtues of testing, I'm going to walk you through a simple example of test-driven development (TDD) using RSpec. The RSpec tool is a Ruby package that lets you build a specification alongside your software. This specification is actually a test that describes the behavior of your system. Here's the flow for development with RSpec:
* You write a test. This test describes the behavior of a small element of your system.
* You run the test. The test fails because you have not yet built the code for that part of your system. This important step tests your test case, verifying that your test case fails when it should.
* You write enough code to make the test pass.
* You run the tests and verify that they pass.

In essence, an RSpec developer turns test cases from red (failing) to green (passing) all day. It's a motivating process. In this article, I walk you through working with the basics in RSpec.

This article gives you 12 practical ways to start writing tests, and keep writing tests, regardless of your development process. The first two techniques play off of things you're probably already doing, so you don't have to move too far out of your comfort zone. The next two challenge you to wade deeper into the pool to realize the benefits of test-driven development. The remaining techniques round out the regimen to keep you testing effectively all year. You'll be well on your way to fulfilling your new year's resolutions. Caution: contents have been known to be infectious!

This article describes two general approaches to automated testing of source code. It covers next technologies used for making tests in Java: JUnit, JMock, FIT. Reader will build sample project step by step and cover it with tests of different kinds. Every practical action will be supplied with theoretical information (or just thoughts if you like).

Test automation is software development. Some people learn this the hard way. But if we take this sentence seriously, wouldn’t it mean that we have to use the same practices to develop our automation code that we use to write our production code? That would mean that we should use continuous integration, code metrics, as well as design patterns. But foremost doesn’t that mean that we should use test-driven development to develop it?

In the context of Java unit testing, a sleeping snail is a test that’s sluggish and takes (relatively speaking) forever to run because it relies on Thread#sleep and arbitrarily long waits to allow threads to execute before performing assertions or continuing with the workflow under test. This article explains this code smell and the appropriate deodorant with an example.

Writing unit tests is not easy. Most of the time, we need to test code that uses complex collaborators such as databases, application servers, or software modules that have not been written yet. We also may need to deal with conditions that are difficult to generate in a test environment. Setting up these dependencies may require a considerable amount of time and energy, counteracting the benefits of having automated tests. This article looks at Mock Objects, a testing technique from the XP community that offers a way to test our code in isolation by simulating those external dependencies. As with any other tool, we need to be careful and avoid overusing them.