Codeception VS Prophecy

Personal experience: - don’t use Behat unless you really needed a “story telling”, it has a intermediate layer Gherkin that you’ll need to code. You can write “Given/When/Then” steps but you’ll also need to write “php code” that will interpret this step. - using real browser be prepared for instability - any interaction with JavaScript can broken/delay execution - be prepared that this tests are call functional they are the most expensive test, so start small unit then integration and only then functional. - use https://github.com/symfony/panther or https://codeception.com/ you’ll have phpunit alike interface to run them. - you’ll need to reset state of your database each time to provide “isolation” and stability

Codeception: https://codeception.com/

I would say to check out Codeception. Codeceptions has modules for Symfony and database generally. Long and short of it is that if you want you can run api tests that go into the controllers and rollback the database afterwards.

There are enough blog posts about Jest or Cypress already, so let me introduce Codecept. It comes in two flavors. There is Codeception for PHP, and there is CodeceptJS for JavaScript which we will be using here.

There are many tools you can use for this purpose, but one I particularly like is CodeCeption. What I like most about it is that it's a unified tool that can be used to perform several types of tests, acceptance being one of them.

This is a quote from this year's new Testify T-Shirt, my physical takeway from this event. While I don't agree that we should automate everything we can, I still chose this design as it shows Codeception code.

And within the Symfony ecosystem Codeception, which “collects and shares best practices and solutions for testing PHP web applications. With a flexible set of included modules tests are easy to write, easy to use, and easy to maintain.”

Prophecy is a framework for creating test doubles that was initially built for the requirements of phpspec, but it can be used with any other PHP testing framework. Since PHPUnit 4.5 it bundles Prophecy within PHPUnit itself, but as of PHPUnit 9.x this bundling is deprecated and set to be removed in PHPUnit 10.

Recently I have been working a lot with PSR-15 and PSR-18 and one of the characteristics of these recommendations is that it uses the immutable objects specified in PSR-7. Soon after we introduced PSR-18 in our codebase a colleague implemented a client including a unit test that was passing. And yet the code was failing when run in the browser. The cause of this was that the fact that RequestInterface objects are immutable by specification was overlooked. Due to the use of Prophecy and prophesized objects we were struggling to properly test it. Until another colleague introduced me to Argument::that() that is.