PHPUnit vs PHPSpec © Rudolf Horváth Unit Testing PHPUnit vs PHPSpec © Rudolf Horváth

Unit Testing The primary goal of unit testing is to take the smallest piece of testable software in the application, isolate it from the remainder of the code, and determine whether it behaves exactly as you expect. Each unit is tested separately before integrating them into modules to test the interfaces between modules.

A good test Able to be fully automated Has full control over all the pieces running (Use mocks or stubs to achieve this isolation when needed) Can be run in any order if part of many other tests Runs in memory (no DB or File access, for example) Consistently returns the same result (Typically no random numbers. Save those for integration or range tests) Runs fast Tests a single logical concept in the system Readable Maintainable Trustworthy (when you see its result, you don’t need to debug the code just to be sure)

PHPUnit The tests for a class Class go into a class ClassTest. ClassTest inherits (most of the time) from PHPUnit_Framework_TestCase. The tests are public methods that are named test*. Alternatively, you can use the @test annotation in a method's docblock to mark it as a test method. Inside the test methods, assertion methods such as assertEquals() are used to assert that an actual value matches an expected value.

Simple example

Test dependencies To quickly localize defects, we want our attention to be focussed on relevant failing tests. This is why PHPUnit skips the execution of a test when a depended-upon test has failed. This improves defect localization by exploiting the dependencies between tests. There can be multiple dependencies

Data Providers Must return Iterator, or arry

Testing Exceptions Or simply try {} catch and see if it’s there

Assertions assertArrayHasKey(mixed $key, array $array[, string $message = '']) assertContains(mixed $needle, Iterator|array $haystack[, string $message = '']) assertContainsOnly(string $type, Iterator|array $haystack[, boolean $isNativeType = NULL, string $message = '']) assertContainsOnlyInstancesOf(string $classname, Traversable|array $haystack[, string $message = '']) assertCount($expectedCount, $haystack[, string $message = '']) assertEmpty(mixed $actual[, string $message = '']) assertEquals(mixed $expected, mixed $actual[, string $message = '']) assertFalse(bool $condition[, string $message = '']) assertTrue(bool $condition[, string $message = '']) assertFileExists(string $filename[, string $message = '']) assertGreaterThan(mixed $expected, mixed $actual[, string $message = '']) assertGreaterThanOrEqual(mixed $expected, mixed $actual[, string $message = '']) assertInstanceOf($expected, $actual[, $message = '']) assertNull(mixed $variable[, string $message = '']) assertSame(mixed $expected, mixed $actual[, string $message = '']) Every assertion has a negative “Not” version with the same parameters

AssertThat

Fixtures

Fixtures setUp(), tearDown()once for each test method (and on fresh instances) of the test case class. setUpBeforeClass(), tearDownAfterClass()before the first test of the test case class is run and after the last test of the test case class is run, respectively. assertPreConditions() assertPostConditions() onNotSuccessfulTest() you only need to implement tearDown() if you have allocated external resources like files or sockets in setUp(). If your setUp() just creates plain PHP objects, you can generally ignore tearDown()

Let’s try those… Download previous lesson’s zip, launch mysql server composer require --dev phpunit/phpunit ^5.7 (6.1 is only for PHP 7+) Change files DataLoader.php (disable output), carService (allow null Request parameter) Change DefaultControllerTest to CarControllerTest Start CarServiceTest phpunit --tap

Test doubles Sometimes it is just plain hard to test the system under test (SUT) because it depends on other components that cannot be used in the test environment. This could be because they aren't available, they will not return the results needed for the test or because executing them would have undesirable side effects. In other cases, our test strategy requires us to have more control or visibility of the internal behavior of the SUT. When we are writing a test in which we cannot (or chose not to) use a real depended-on component (DOC), we can replace it with a Test Double. The Test Double doesn't have to behave exactly like the real DOC; it merely has to provide the same API as the real one so that the SUT thinks it is the real one!

Test doubles getMock($className) By default, all methods of the original class are replaced with a dummy implementation that just returns NULL (without calling the original method). Using the will($this->returnValue()) method, for instance, you can configure these dummy implementations to return a value when called. final, private and static methods cannot be stubbed or mocked. They retain their original behavior.

Stubs

Stubs (with MockBuilder)

Stubs (with MockBuilder) setConstructorArgs(array $args) setMockClassName($name) disableOriginalConstructor() disableOriginalClone() disableAutoload() any() once() never() atLeastOnce() exactly() at(index) returnValue() returnArgument() returnSelf() returnCallback() (throwException())

Code Coverage Code Coverage

Test Driven Development Drives out the functionality the software actually needs, rather than what the programmer thinks it probably ought to have When to write test? - Long after development - Shortly after development or - before? Problems (?): - When you first write the test it cannot possibly run - Feels strange at first (programming to an interface instead of programming to an implementation)

Behaviour-Driven Development Traditional TDD tools still force developers to think in terms of tests and assertions instead of specifications. It's about figuring out what you are trying to do before you run off half-cocked to try to do it. You write a specification that nails down a small aspect of behaviour in a concise, unambiguous, and executable form. It's all about specifying behaviour and not writing tests. Suddenly the idea of having a Test class for each of your production classes is ridiculously limiting. And the thought of testing each of your methods with its own test method (in a 1-1 relationship) will be laughable.

The other way

PHPSpec Test class names end with “Spec”. The spec extends the special ObjectBehavior class. This class is special, because it gives you ability to call all the methods of the class you are describing and match the result of the operations against your expectations. Method names are underscored, starting with “it_” or “its_”

Matchers Matchers are much like assertions, except the fact that matchers concentrate on telling how the object should behave instead of verifying how it works. Identity (return, be, equal, beEqualTo) it’s like checking === Comparison (beLike) it’s like checking == Throw (throw -> during) for testing exceptions Type (beAnInstanceOf, returnAnInstanceOf, haveType) checks object type ObjectState (have**) checks object is** method return value

Matchers

Identity matcher

Comparison matcher

Throw matcher

Type matcher

ObjectState matcher

Count matcher

Scalar matcher

Stubs - Prophecy $prophecy = $prophet->prophesize('MyClass'); $prophecy->read('123')->willReturn('value'); ReturnPromise [->willReturn(1)] returns a value from a method call ReturnArgumentPromise [->willReturnArgument()] returns the first method argument from call ThrowPromise [->willThrow] causes the method to throw specific exception CallbackPromise [->will($callback)] gives you a quick way to define your own custom logic Keep in mind, that you can always add even more promises by implementing Prophecy\Promise\PromiseInterface.

Stubs Method prophecy Argument wildcarding

Stubs - Argument wildcards ExactValueToken [Argument::exact($value)] checks that the argument matches a specific value TypeToken [Argument::type($typeOrClass)] checks that the argument matches a specific type or classname. ObjectStateToken [Argument::which($method, $value)] checks that the argument method returns a specific value CallbackToken [Argument::that(callback)] checks that the argument matches a custom callback AnyValueToken [Argument::any()] matches any argument AnyValuesToken [Argument::cetera()] matches any arguments to the rest of the signature

Mocks and call predictions $prophet->someMethod()->shouldBeCalled() CallPrediction [shouldBeCalled()] checks that the method has been called 1 or more times NoCallsPrediction [shouldNotBeCalled()] checks that the method has not been called CallTimesPrediction [shouldBeCalledTimes($count)] checks that the method has been called $count times CallbackPrediction [should($callback)] checks the method against your own custom callback Verify predictions with $prophet->checkPredictions();

Spies Prophecy records every call made during the double's entire lifetime. This means you don't need to record predictions in order to check them. You can also do it manually MethodProphecy::shouldHave(PredictionInterface $prediction)

let and letGo class MyMailingServiceSpec extends ObjectBehavior { public function let($mailer) $mailer->beAMockOf('\Swift_Mailer'); $this->beConstructedWith($mailer); } public function letgo() // release any resource // put the system back into the state it was