Test and Quality Assurance section of the Software Development Articles Directory.

This article written in May 2007 examined three tools that purport to verify that your Web services do what they are supposed to do, that they resist graceless failure, and (in some cases) that they conduct themselves with efficiency. The tools are soapUI, TestMaker, and WebInject. All are open source, and are available for free download and incorporation into your next Web services project.

Test Infected! The original article on Test Driven Development by Kent Beck and Erich Gamma. A great primer on TDD and an intro to how to use JUnit.

This article explores the two types of mocks that exist and covers some of the problems inherent in their use. Finally, it considers the reason why a developer might chose to use mocks. After all, common understanding holds that mocks are used for unit testing, a key part of Test Driven Design

This document is an attempt to filter out guidelines about Test First Design from the XP series of books. It is not intented to justify Test First Design, but just want summarize what Martin Fowler's Refactoring and the XP texts have to say on the subject.

Unit testing is a fundamental practice in Extreme Programming, but most non-trivial code is difficult to test in isolation. It is hard to avoid writing test suites that are complex, incomplete, and difficult to maintain and interpret. Using Mock Objects for unit testing improves both domain code and test suites. They allow unit tests to be written for everything, simplify test structure, and avoid polluting domain code with testing infrastructure.

This paper gives a complete description of code coverage analysis (test coverage analysis), a software testing technique.

Lessons learned on the road to 100% code coverage. What is 100% code coverage? Code coverage is a metric that tells you how much of the source code for an application is run when the unit tests for the application are run. If 100% of the lines of source code are run when the unit tests are run, then you have 100% code coverage.

Test coverage tools bring valuable depth to unit testing, but they're often misused. This article takes a closer look at what the numbers on the coverage report really mean, as well as what they don't. He then suggests three ways you can use your coverage to ensure code quality early and often.

Testing is firmly entrenched in the Ruby on Rails community. Many tools can help you, from the Rails stack to RCov for coverage to Mocha and FlexMock for enhancing your test cases. But different tools often support diverging strategies. Learn about the trade-offs of several basic testing strategies.

Systir stands for System Testing In Ruby. This doesn’t mean “system testing of Ruby code”; rather, it means we used Ruby to create a tool for helping you automate your system tests. In short, Systir allows you to write system-level tests in a “domain language”; that is, a custom language that pertains to your target software functionality and its own particular constructs.

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

Unit testing is a fundamental practice in Extreme Programming, but most non-trivial code is difficult to test in isolation. It is hard to avoid writing test suites that are complex, incomplete, and difficult to maintain and interpret. Using Mock Objects for unit testing improves both domain code and test suites. They allow unit tests to be written for everything, simplify test structure, and avoid polluting domain code with testing infrastructure.

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.

Martin Fowler, chief scientist at Thoughtworks, Inc. and author of numerous books on software design and process, talks with Bill Venners about the unhurried quality of test-first design and monological thinking, and the difference between unit and functional testing.

Although developers have been unit testing their code for years, it was typically performed after the code was designed and written. As a great number of developers can attest, writing tests after the fact is difficult to do and often gets omitted when time runs out. Test-driven development (TDD) attempts to resolve this problem and produce higher quality, well-tested code by putting the cart before the horse and writing the tests before we write the code. One of the core practices of Extreme Programming (XP), TDD is acquiring a strong following in the Java community, but very little has been written about doing it in .NET.

Test-driven development is not about testing. Test-driven development is about development (and design), specifically improving the quality and design of code. The resulting unit tests are just an extremely useful by-product. That's all I'm going to tell you about test-driven development. The rest of this article will show you how it works. Come work on a project with me; we'll build a very simple tool together. I'll make mistakes, fix them, and change designs in response to what the tests tell me. Along the way, we'll throw in a few refactorings, design patterns, and object-oriented design principles. To make this project fun, we'll do it in Python.

Applying Mock objects effectively is a key factor when performing Test Driven Development (TDD). In this article I'll introduce the basics of using JMock, a Mock object framework, in conjunction with Test-Driven Development. To illustrate the technique I will work through a case study, the creation of a cache component by means of test-first development with JMock.

An article on Story Test-Driven Development (STDD)

In the first article in this series, Test-Driven Development with Python, Part 1, I started to build an event tracking application using the principle of test-driven development. Before writing any new code or making changes to any existing code, I wrote a failing test first. When the new test started passing, I stopped and moved on. It's a simple technique, but requires discipline in order to apply it successfully.