Tips for testing web applications

Hey everyone!

Here are some tips that might help you test your applications. I had it previously posted as a twitter thread. Sadly I could not inline images here so it might be useful to look at the thread.

1. Don't be afraid to hit the database. Today DB calls are very fast, and if you're mocking the database you're usually not testing the feature completely. It makes sense to write "pure" unit tests on lower-level things like libraries, though.
2. Reverse test when testing code that already exists. A easy way to make sure your new tests cover an existing feature is to comment out blocks of code (specially if blocks) and see if the tests break. If they don't, you're missing something.
3. It's better to write some "unnecessary " tests than not to write them, so If you're wondering wether a test will be useful, just write it. Those few minutes might help you a lot later.
4. Use fakes instead of mocking external services when possible. Laravel ships with many fakes, and when you need a custom one it's easy to swap the implementation for a fake on the container. That's possible on anything that has a container. The tweet ocntains an example using Laravel's Facades.
5. Tests are important, but don't let them hold you back. If you feel thinking how the API is going to look before writing the code is holding you back, just forget the tests for a moment. You can come back later and write them. Writing them before is not a exactly a rule.

Comments

[Oziel Perez]

The best way to "Mock a database" is to create a SQLite database on the fly inside your unit tests and test against that. That way whatever code you're using to fetch and post data can be tested against that, should you not want to hit your database directly. As for hitting the real database, this should be part of a larger "Integration Test", where you start all the way at the front end by making a web request and ensuring that your data is fetched/posted properly at the database.

[Robson Tenório]

But just remember sometimes if you use an special DB function SQLite won’t be enough.

[This Dot Media]

Great point Oziel

[Vlad Kucherov]

1. Use SQLite in memory, that is fast... External DB calls aren't fast at all. I expect lots of tests to finish in matter of seconds. Tests should check whatever is related to what you want to make sure is working (sorry for the ambiguous sentence). That means that if you need to test something is stored in the DB (I mean that is your intent) then go to the DB and check it. BUT! if you are checking a service (A) that uses another service (B) which does a DB request, you should mock B and not the DB for better tests isolation.
2. If the code already exists, and there are not tests, yea you're probably right about removing chunks of code. Better yet write the test first, see it fail, and then write the code to make it pass. That way you shouldn't have untested and unnecessary code. If that is not an option (the code is already written) start with reading the code and try to understand what it does, and add a test for that little by little, and use coverage to find untested branches in the code.
3. If the point is to convince someone to write tests, that is a helpful tip. In real world scenario I would never want to waste my time on checking things I don't understand why I need them.
4. Just to clarify, from my understanding Laravel ships with mocks (fakes) for internal features like events, storage, etc... Yea they're good for that they were intended to do, but still if I need to mock some library for a unit test, I would rather mock it right away without messing with Laravel at all...
5. TDD rules! write tests first!

[This Dot Media]

Love these! 🙌