Unit testing, yay or nay?

“Unit tests are widely understood in the software development field as a type of test that verifies the “correctness” of a part of an application, typically a single function or method. It ensures that the unit of code works as expected in isolation from the rest of the application” → ChatGPT

Unit testing is pretty much a given for 99% of development projects being worked on as of 2024. Running a unit test to ensure that when a user clicks on a button to view a page, that page is loaded and contains the expected data is never going to be a bad thing, especially when said application is being worked on by a team of developers - building a comprehensive set of tests for any significant change being submitted is going to save said developers a lot of time in figuring out how the changes are going to impact the existing system as well as adding another QA layer when working with Selenium and other automated test suites.

That being said, my question today is more of a “return on investment” argument for smaller projects such as websites or one-time-use applications being implemented either by limited development teams or even individuals such as myself

For those who don’t know, Laravel is a PHP framework designed for web application development, emphasising elegant syntax, a modern toolkit, and a lot of developer-friendly features. To put it simply, Laravel is a “boilerplate” web application that allows developers to very quickly build the models, controllers, database tables, pages etc. needed for the site.

A quick example of what Laravel, or any other MVC framework can do: Imagine you are building a shopping website like Amazon or eBay with hundreds of products that you are looking to sell. Building a site like this via “traditional” means (Without using a framework) would mean creating a page with all the information about the product for every single one of said products. Any time you wanted to update a listing, you would have to bring up the raw HTML for that product one by one and update the content

Laravel one the other hand allows us to create a product page template (called a blade) and store the information for the products in a database instead. That way there is only ever 1 page being loaded, with the details of the product being loaded dynamically onto said page. In this scenario, the product is what's known as a “model”

• In order to cover the functionality of a site such as this with a unit test, we would need to assert a few things;
• The page is loaded successfully
• The details of the product that appear on the page match the specified product in the database (i.e. the correct product is loaded in)
• Any forms, links, filters etc on the page work as expected when interacted with by the user

We also have to factor in testing the backend functionality of creating, updating and deleting products with tests not only for each of these functions themselves, but ensuring the pages or popups for each of these actions is displayed correctly and that the content is saved correctly to the DB

Tests like these, as well as tests that cover user authentication and transactional data for example should provide enough coverage to ensure the site is working as expected. The problem however, is that most websites, regardless of the type of site (e-commerce, social, advertising etc) will have more than one model in the form of blog posts, pages, products, social media links, events, photo albums etc. Each of these models will need the aforementioned test coverage for rendering correctly with the correct content as well as the suite of backend tests.

Speaking from experience, I know for a fact that when I'm implementing new models into a site, the first thing I do is check that the create and edit forms show up with the correct content, and that when I type content into said forms and press submit, i can see my changes on the frontend - I already know if something isn’t loading correctly when I write the lines of code that cause the content to appear. Surely all a unit test will do in that case is confirm what I already know and add more hours to the project, especially since I will need to do this again and again and again for each model - so whats the point?

The answer potentially lies in looking ahead at the potential benefits of unit testing in the long run. While it might seem like overkill right now for small projects or those with a short lifespan, it is true that unit tests provide a safety net, allowing for refactoring and changes to be made later on down the line. Even thought I’m the sole developer right now, unit tests will inevitably catch edge cases that might be overlook during the manual testing I mentioned earlier. Documenting the EXPECTED behaviour of the code can also be invaluable when it comes time to revisit the project later or if it eventually grows in complexity.

Plus its probably worth remembering that in a collaborative environment, unit tests do absolutely help ensure that different developers’ changes do not inadvertently break one another's code. They help us facilitate smoother integrations and deployment processes, reducing (but not removing) the likelihood of bugs making their way into production.

In conclusion, while unit testing might seem like an unnecessary burden for small, one-off projects, its benefits become more apparent as the project grows or if maintenance is required over time. By investing in unit tests strategically and focusing on the most critical and complex parts of the application, we can (probably) strike a balance between developing efficiently and coding reliably. Ultimately, unit testing is not just about preventing immediate bugs; it’s also about fostering and maintaining a reliable development process that can be adapted and thrive with the project as it evolves