Spec: Testing

Abstract

This document is an extension of Spec: Coding. The goal of this document is to keep core tests consistent. We suggest you follow the same rules in your own projects. For more information see the section on Lithium's Unit Testing Framework in the manual.

Class Names

Class names should be the name of the class you are testing with the Test suffix.

class ObjectTest extends \lithium\test\Unit {

}

Mocks

Often you need to create a mock class to override some functionality of the class you are testing. A mock class will have a prefix of Mock and be located in the a parallel namespace of the class being tested.

namespace lithium\tests\mocks\http;

class MockSocket extends \lithium\util\Socket {

}

In the above example we are going to be using the Mock to test a class in the lithium\http namespace.

Assertions

Assertions should follow the expected -> result format.

$expected = 'works';
$result = Do::somthing();
$this->assertEqual($expected, $result);

Always use the right assertion that does the job. The assertion methods are made available through the Unit class from which most tests directly or indirectly inherit. Have a look at the Class Methods section on API Browser/Unit.

$this->assertTrue($result);
$this->assertFalse($result);
$this->assertNull($result);
// ...

Coverage

The Lithium test coverage policy requires:

1. A corresponding test exists for each class.
2. All classes have a test coverage of 85% and higher.

These 2 conditions must be met before the project reaches stable.

The current status for Lithium regarding test coverage is tracked through a ticket in our tracking system. Missing tests or coverage are considered a bug.