Love it or hate it, testing is a necessary evil. It proves that your application works as intended and hopefully covers off any “unwanted features” slipping in. With the recent rise in TDD, I’m going to dive into the different methods of testing, and how you can implement each one in your organisation.
There are various methods of testing, they will either be functional or non-functional. For this article, I’ll only be looking at the functional tests. I’ll be sure to do a follow-up article about the non-functional in the near future.
Functional tests can be broken down into many, many, different categories – depending on how granular you feel like being. However, for your sanity as a reader, I’ll keep the list short and concise.
The process in which the developer / programmer takes apart the core classes / objects within an application, and writes tests to ensure that the “Unit” works in isolation.
The definition of a “Unit” is technically the smallest possible version of a resource. However this is often argued in teams. Just how granular do you go? Is a Class a Unit? A method? Do you have to write a test for every getter and setter? What about magic methods? The list goes on.
Integration / Feature Testing
One level up from Unit testing, Integration tests ensure that your “Units” can work together and achieve expected results.
An example of this would be, I have a request coming in that should store a record in the database. I’ll need an Integration/Feature test for the process around that request. The flow of which would be;
- Request comes in (randomly generated data)
- Request is handled
- Confirm validation checks
- No session errors
- Response code is as expected
- Response body is as expected (JSON structure, or contains certain things)
- Database now contains expected data
I’d also expect to see tests for intentionally bad requests to ensure that they are handled accordingly and the database is missing the data.
You know the little pieces should work, and those pieces fit together. Now for the full puzzle.
Can you, as a user, navigate through each page without fault. Add data as expected? Functionally, does the site work as intended?
This can be done in a number of ways with Laravel. You can test it yourself, as a developer on a local instance of the application using Homestead, or Valet. Equally, you could write Dusk tests which will run Chrome in a headless mode and run automated browser tests for you.
This is a good chance to give your application to other developers in your team as well, see if there’s something that they can think of that potentially you’ve missed along the way.
Hands off the project. Give it to a 3rd party, or completely isolated user group. Let them destroy it. You want them to find any and all bugs possible at this stage. After this, it’s deploy / hand over – so there’s no turning back!
The great thing about this type of testing is that Users are really really stupid at the best of times. But you need to cover this off.
User testing will involve things like;
- Cross browser compatibility
- Form Validation
- Putting a name into a DOB field, because they can
- Uploading a 2GB file, again because they can
- General UX and UI feedback
- Cross platform/device testing
- The dreaded “does it work on iPad in both portrait and landscape mode”
- Do you support IE? To what versions? Are your users aware of this? How is that handled?
What’s this TDD I always hear about?
TDD is Test-Driven Development. The core idea is that the developers will write their Unit and Feature tests before any application / business logic is written.
You then write the code to pass the test, and refactor once all tests are passing. The biggest takeaways from this is that you have a naturally tested environment and your application is, for the most part, more stable when making changes in the future.
Adding new features will be less prone to sneaky bugs due to unforeseen impact on other elements – as those existing elements have their tests to ensure that they’re compatible with requirements.
It’s a great methodology and I thoroughly recommend bringing it into your workflow if you can. It is a little slower to produce results for clients though – which doesn’t always go down well. It does however deliver more stable, maintainable, and extensible solutions; so there’s a great trade off if you can get it in.