Unit testing is something we all need to do, but getting good code coverage can be a daunting task. In this article, Gary Tong focuses on one of the basic elements of unit tests: mock objects. Using a hybrid static/dynamic approach, he shows how flexible, useful mock objects can be written in a matter of minutes.

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

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.

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

Mocking frameworks, such as Mockito, are powerful tools for testing and test-driven development (TDD) in particular. But sometimes, it can be a little confusing to decide what to mock and how to mock.

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).

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.

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?