

Unlike using the UnitTester class for this purpose, using a module directly grants you access Accessing ModuleĬodeception allows you to access the properties and methods of all modules defined for this suite. This is done by wrapping each test in a transaction and rolling it back afterwards. The Doctrine2 and Laravel modules will clean up the created data at the end of a test. In both examples you should not be worried about the data persistence between tests. tester -> haveInRepository ( User :: class, ) // get entity manager by accessing module $em = $this -> getModule ( 'Doctrine2' ) -> em // get real user $user = $em -> find ( User :: class, $id ) $user -> setName ( 'bill' ) $em -> persist ( $user ) $em -> flush () $this -> assertEquals ( 'bill', $user -> getName ()) // verify data was saved using framework methods $this -> tester -> seeInRepository ( User :: class, ) $this -> tester -> dontSeeInRepository ( User :: class, ) } We won’t need its web interaction methods like amOnPage or see, Why not use ORM directly inside your tests? Let’s try to write a test using Laravel’s ORM Eloquent.įor this we need to configure the Laravel module. You should probably not access your database directly if your project already uses ORM for database interactions.

See Db Module Interacting with the Framework If that’s not your required behavior, change the settings of the Db module for the current suite. The database will be cleaned and populated after each test, the same way it happens for acceptance and functional tests. To enable the database functionality in unit tests, make sure the Db module is included setName ( 'Miles' ) $user -> setSurname ( 'Davis' ) $user -> save () $this -> assertEquals ( 'Miles Davis', $user -> getFullName ()) $this -> tester -> seeInDatabase ( 'users', ) } Stubs can also be created using static methods from Codeception\Stub class. create a stub with find method replaced $userRepository = $this -> make ( UserRepository :: class, ) $userRepository -> find ( 1 ) // => User // create a dummy $userRepository = $this -> makeEmpty ( UserRepository :: class ) // create a stub with all methods replaced except one $user = $this -> makeEmptyExcept ( User :: class, 'validate' ) $user -> validate ( $data ) // create a stub by calling constructor and replacing a method $user = $this -> construct ( User :: class, , ) // create a stub by calling constructor with empty methods $user = $this -> constructEmpty ( User :: class, ) // create a stub by calling constructor with empty methods $user = $this -> constructEmptyExcept ( User :: class, 'getName', ) $user -> getName () // => davert $user -> setName ( 'jane' ) // => this method is empty This tiny library adds more readable assertions, which is quite nice, if you are always confusedĪbout which argument in assert calls is expected and which one is actual: You may add Codeception\Verify for BDD-style assertions. The most common are:Īssertion methods come from PHPUnit. There are pretty many assertions you can use inside tests.

SetName ( null ) $this -> assertFalse ( $user -> validate ()) $user -> setName ( 'toolooooongnaaaaaaameeee' ) $this -> assertFalse ( $user -> validate ()) $user -> setName ( 'davert' ) $this -> assertTrue ( $user -> validate ()) } } Assertions
