Pengujian unit
Manfaat > Desain

Ketika perangkat lunak dikembangkan dengan menggunakan pendekatan digerakkan pengujian, kombinasi dari menulis pengujian unit untuk menentukan antarmuka, ditambah dengan kegiatan refaktorisasi yang dilakukan setelah kelulusan uji, dapat mengambil alih desain formal. Masing-masing pengujian unit dapat dilihat sebagai elemen desain untuk menentukan kelas-kelas, metode, dan perilaku yang dapat diamati. Berikut contoh dalam bahasa pemrograman Java yang akan membantu menjelaskan hal ini.
Berikut ini adalah sekumpulan kasus uji yang menentukan sejumlah unsur-unsur implementasi. Pertama, harus ada sebuah antarmuka yang disebut Adder, dan kelas yang mengimplementasi dengan konstruktor tanpa argumen yang disebut AdderImpl. Kemudian kasus uji ini menegaskan bahwa antarmuka Adder harus memiliki sebuah metode yang disebut add, dengan dua parameter integer (bilangan bulat), yang menghasilkan integer pula. Kasus uji ini juga menentukan perilaku dari metode ini untuk kisaran nilai tertentu pada serangkaian metode uji.
import static org.junit.Assert.*;

import org.junit.Test;

public class TestAdder {

    public void testSumPositiveNumbersOneAndOne() {
        Adder adder = new AdderImpl();
        assert(adder.add(1, 1) == 2);
    }

    // can it add the positive numbers 1 and 2?
    @Test
    public void testSumPositiveNumbersOneAndTwo() {
        Adder adder = new AdderImpl();
        assert(adder.add(1, 2) == 3);
    }

    // can it add the positive numbers 2 and 2?
    @Test
    public void testSumPositiveNumbersTwoAndTwo() {
        Adder adder = new AdderImpl();
        assert(adder.add(2, 2) == 4);
    }

    // is zero neutral?
    @Test
    public void testSumZeroNeutral() {
        Adder adder = new AdderImpl();
        assert(adder.add(0, 0) == 0);
    }

    // can it add the negative numbers -1 and -2?
    @Test
    public void testSumNegativeNumbers() {
        Adder adder = new AdderImpl();
        assert(adder.add(-1, -2) == -3);
    }

    // can it add a positive and a negative?
    @Test
    public void testSumPositiveAndNegative() {
        Adder adder = new AdderImpl();
        assert(adder.add(-1, 1) == 0);
    }

    // how about larger numbers?
    @Test
    public void testSumLargeNumbers() {
        Adder adder = new AdderImpl();
        assert(adder.add(1234, 988) == 2222);
    }

}
Dalam hal ini pengujian unit, karena telah ditulis terlebih dahulu, bertindak sebagai dokumen desain yang menentukan bentuk dan perilaku dari solusi yang diinginkan, tapi tanpa perincian pelaksanaan. Perincian ini diserahkan kepada pemrogram. Mengikuti praktik "melakukan hal yang paling sederhana yang mungkin bisa bekerja", solusi termudah yang akan lulus pengujian ditunjukkan di bawah ini.
interface Adder {
    int add(int a, int b);
}
class AdderImpl implements Adder {
    public int add(int a, int b) {
        return a + b;
    }
}
Tidak seperti metode desain berbasis diagram lainnya, menggunakan pengujian unit sebagai desain spesifikasi memiliki satu keuntungan penting. Dokumen desain (pengujian unit itu sendiri) dapat digunakan untuk memverifikasi bahwa implementasi mematuhi desain. Dengan metode desain pengujian unit, kode tidak akan pernah lulus uji jika pengembang tidak melaksanakan solusi sesuai dengan desain.
Memang benar bahwa pengujian unit tidak lebih mudah dipahami dibandingkan diagram, tetapi diagram UML saat ini dengan mudah dihasilkan buat sebagian besar bahasa-bahasa pemrograman modern menggunakan alat-alat gratis (biasanya tersedia sebagai ekstensi untuk IDEs). Alat-alat gratis ini, seperti yang berdasarkan kepada kerangka kerja xUnit kerangka, mengalihkan ke sistem lain tampilan grafis diagram untuk konsumsi manusia.