Is there any theoretical guide for Laravel testing?

@realtebo the best way to learn is from the expert :P

Watch anything in the PHPUnit series

• https://laracasts.com/topics/phpunit

particularly

• https://laracasts.com/series/phpunit-testing-in-laravel

and any of the TDD series.

For testing vue, look at this series

• https://laracasts.com/series/cypress-and-laravel-integration

I appreciate your reply.

I am looking for a less-practical and more theoretical course.

I woul give a chance to each 3 of these, but I need infos about how to evaluate what and how to test and not about doing specific testing with phpunit or something else. My dubt is how to choose phpunit vs cypress, for example, and about each testing strategies what are specific pros and cons.

When to do unit tests and when to do e2e ? etc....

The main difference between unit and e2e (functional) is what you are testing.

With unit, you are testing a single unit of code, by setting input parameters and comparing with expected output, Generally you would write a group of tests to cover all ‘public’ methods in your class, mocking external dependencies so that everytime your test is run it returns the same result, and is not reliant on external services that could influence the results. You’d generally use these for model tests. E2e tend to test wider scope so you might test a registration process, or visiting a page and expecting to see rendered content. You should also mock external systems eg if your method called an external api you would mock the response of that and then assert your response reflects your mocked data.

See https://www.toptal.com/qa/how-to-write-testable-code-and-why-it-matters

The real value of testing is to use it as a scaffolding in development of your code (known as Test Driven Development).

When you are coming up with new functionality, you’d create a new test to define your inputs and expected, and continue to write the minimum amount code until that test passes. At that point you’d write an additional test for the same unit, run the test (old test passes, new one fails), modify code until both tests pass, carry on.

This is known as red/green/refactor.

In laravel it can get a bit woolly which is unit and which is e2e but imho if you would test in a browser it’s e2e otherwise it’s a unit.

With laravel, your smallest units tend to be in models so you would use factories to mock model data, and you would also need to ensure that you test against a know state of your database so would run migrations before your unit is tested and then roll back after, on a database separate to your application database.

In many testing frameworks like phpunit you can also run code coverage and quality reports so you can see how much of your application you have covered and also identify any bits that could be tightened up with type hinting or by splitting to smaller methods.

Additionally TDD there is also BDD (business driven development) and DDD (domain driven development) which allow for testing application by defining business requirements first and writing e2e tests to test assertions. Look at gherkin and cucumber for this and a package called behat which is the php port of this. I’ll let you google for for this when you are familiar with the basics.

Hopefully the above is a good overview.