A unit test is a fast, automatic and repeatable way of proving your code does what it is supposed to do. It confirms that your code still works after you have made changes, or alerts you early on to the fact that something has broken. By writing unit tests that cover all of our code, we can quickly run them and check our entire application in a few seconds.

A unit test even acts as a piece of documentation as it describes how your code should be used.

Before the development community was convinced of the benefits, some people thought that unit tests were a waste of time. Some developers thought that their job was to write production code, so spending time on unit tests, which aren't production code, wasn't what they were being paid for.

These days, most professional developers know that unit tests are an important part of writing production code. It means you deliver better quality code and it makes jobs like refactoring or adding new features easier.

The research team found was that the TDD teams produced code that was 60 to 90 percent better in terms of defect density than non-TDD teams - via Phil Haack .

If your code isn't covered by unit tests, it is legacy code.

A unit test isolates a small part of your code for testing purposes. Components that your code depends on are replaced with fake versions to make your test more stable. An integration test covers many components in a single test.

Usually a unit test calls a single method in a single class and tests a single piece of logic in that method, whereas an integration test ensures that two components interact as expected.

You should have as much unit test coverage as possible to ensure that the behaviour of your code is what you expect it to be. Integration test coverage should not test the detailed behaviour of the code (as this is already covered by unit tests) but instead focus on proving that components are present, connected and interact.

You can perform unit testing and integration testing with Enhance PHP.

A test should only test a single logical unit. If you are making multiple assertions in a test, you should consider whether there should be multiple tests with a single assertion instead. If one test fails, it should be clear exactly what logic is broken; if you test too much in a single test it is hard to discern the cause of the failure.

Public Methods:

You should only test public methods. If the public method calls private methods, you can design your tests to exercise the different parts of logic contained in the private methods by calling the public methods with the right combination of arguments.

Dependencies:

If the class or function you are testing relies on some other component, you should supply a fake version of that component in order to isolate your test. You don't want changes in another component to affect your tests.

Naming:

The name of your test should be descriptive enough to tell you what has gone wrong if it fails. For example:

[MethodName] With [Condition] Expect [Outcome]

A real example would be:

AddTwoNumbersWith3And5Expect8

Some people use underscores instead of the "With" "Expect" syntax.

[MethodName]_[Condition]_[Outcome]

public function addTwoNumbersWith3and2Expect5() {
	$target = \Enhance\Core::getCodeCoverageWrapper('ExampleClass');
	$result = $target->addTwoNumbers(3, 2);
	\Enhance\Assert::areIdentical(5, $result);
}

This test is for a method called "addTwoNumbers", which is a simple addition function. We test it by passing in 3 and 2, and by proving that the response is 5. If the method gave back any other value the test would fail.

A "fake" is a dummy class or object that you use in place of a real one for the purposes of testing. For example, if you had some code that relied on a class called "TaxCalculator", you wouldn't want to use the real Tax Calculator in your tests as this would make your tests brittle. If the Tax Calculator changes, it could cause your tests to fail despite the fact the code and behaviour of your code under test being correct. So instead of using the real Tax Calculator, which currently calculates tax at 22%, but next year may be 20% or 25% we create a fake one that always uses the same percentage. Now our tests won't be affected by changes in the tax calculator and will be less brittle.

Mocks and stubs are the two types of "fake" used in unit testing. A stub simply acts as a stand-in to allow the tests to run, whereas a mock is used to verify that certain calls with made with particular arguments. So a stub is just there to make your tests happen without relying on outside classes and a mock is used to pass or fail a test (i.e. if your code doesn't call a method it should call, or if it calls a method it shouldn't have called, you can fail the test).

You can hand-crank either a mock or a stub by writing a class with the same interface as the real class, and hard coding the return values. However, to save you the trouble, Enhance PHP will generate them for you.

Create a mock and add an expectation:

$mock = \Enhance\MockFactory::createMock('ExampleClass');
$mock->addExpectation(\Enhance\Expect::method('addTwoNumbers')->with(3, 5)->returns(8)->times(1));

Pass it in to the class as a dependency:

$myClass = new MyClass($mock);

Verify the method was called the correct number of times with the correct arguments.

$mock->verifyExpectations();

Create a stub and add any required return values:

$stub= \Enhance\MockFactory::createStub('ExampleClass');

$stub->addExpectation(\Enhance\Expect::method('addTwoNumbers')->with(3, 5)->returns(8));

Pass it in to the class as a dependency:

$myClass = new MyClass($stub);

Test-Driven Development is the process of only writing production code once you have a failing test. You first write the test to verify a single part of the functionality of your application, then you write the minimum amount of code to make it work.

If TDD takes 35% longer, it more than pays for itself. "defects found 'in the field' cost 50-200 times as much to correct" - via Phil Haack .

Here is a quick example...

<?php
// Example built using TDD
include('../EnhanceTestFramework.php');
class ExampleClass {
	public function addTwoNumbers($a, $b) {
	}
}
class ExampleTestFixture extends \Enhance\TestFixture {
	private $target;
	
	public function setUp() {
		$this->Target = \Enhance\Core::getCodeCoverageWrapper('ExampleClass');
	}
	
	public function addTwoNumbersWith3and2Expect5() {
		$result = $this->Target->addTwoNumbers(3, 2);
		\Enhance\Assert::areIdentical(5, $result);
	}
}
\Enhance\Core::runTests();
?>

	public function addTwoNumbers($a, $b) {
		
	}

	public function addTwoNumbers($a, $b) {
		return 5;
	}

	public function addTwoNumbersWith4and2Expect6() {
		$result = $this->target->addTwoNumbers(4, 2);
		\Enhance\Assert::areIdentical(6, $result);
	}

	public function addTwoNumbers($a, $b) {
		return $a + $b;
	}