- #1: Introduction (i.e This article 😁)
- #2: Setting up Next.js Project for testing
- #3: Writing the tests
- #4: Are my tests enough?
Tests - one of the most important things in software development, yet one of the most neglected.
Who can we really blame? After journeying across seven seas and climbing four great mountains, I finally came face to face with the culprit. Its name is: (drum roll please)
🥁🥁
🥁🥁🥁🥁
🥁🥁🥁🥁🥁🥁
🥁🥁🥁🥁🥁🥁🥁🥁
🥁🥁🥁🥁🥁🥁🥁🥁🥁🥁
TIME! Yes, TIME is the great culprit.
More often than not, every project has a business deadline to meet up with, a specific time when the business needs to hit the market before other competitors come in and steal the desired market, or before an investor runs out of patience on the funds they invested 😂. Unfortunately, when writing tests - be it before development or after - it always takes a considerable amount of time, so one has to be careful in gauging when exactly to write tests. It almost seems like we are always racing against time, am I right?
Regardless, despite the time it takes, there is no doubt that a well tested application would definitely stand the test of time, because well-written tests ensure a well-written application.
That been said, when it comes to testing, there are generally two approaches one could take based on when to write tests:
- Test Driven Development (TDD)
- Test After Development (TAD)
Test Driven Development (TDD)
This is the ideal approach to testing, mainly because as the name goes, it ensures that your development process is driven by your tests. So, in simple terms, if you are creating a page with some functionality, it is your tests that drive how you create the logic for that page. Usually you create the tests first, then you create your logic to pass the already written test.
- The main advantage of this approach is that your app is guaranteed to almost never break since you are writing your application to fulfill some already written down tests
- The main disadvantage of this approach is the development time it takes. If your application could be built under 2 months without tests, trust me by using TDD approach it might take a lot more than that
Test After Development (TAD)
In this approach, your tests do not drive the development of your application; instead they are created to confirm code that has already been written.
The main advantage of this approach is that you can quickly deploy your application if your company has a strict business deadline that makes adding tests at the initial stage not feasible, and thereafter when things are no longer "hot", and project managers are not breathing down your neck for the completion of a task, you can then write your tests.
The main disadvantage of this approach is that, it is very easy to write bad tests. When I say bad tests I mean since you would be writing tests to confirm a logic that already exists, what guarantees that the logic that already exist is good? This implies that if your code is bad, you would be essentially writing test to pass bad code. I'm sure you can see the danger there.
In the grand scheme of things you should always strive to use the Test Driven Development (TDD) approach, however since we cannot always have what we want, the true answer to which approach you take towards testing still balls down to the most accepted developer answer to any question in the universe :
It depends
It depends
If your company has the time to spare, definitely go for Test Driven Development, but if they do not (you can remember our little talk about time at the beginning of this article), then its adviceable to go for Test After Development.
Let's face facts, more often than not unless your company is already well funded or has some plan that can accommodate the time TDD takes, you might be on a tight deadline to push a certain feature out, so it would most likely be better for you to go with the Test After Development approach. In all sincerity Test After Development with the addition of coverage(we would talk about that more in a later article), when done carefully could be as good as Test Driven Development.
What we would be looking at
After all these while writing tests, I decided to give a detailed walk-through on writing tests, hence this article and a couple of others. We would build an application and test it just the same way we would do for any enterprise grade application. We would assume our application belongs to a growing startup that quickly wants to push out the product in order to have something to demo for investors.
In this Testing series we would be looking at
- Testing Frontend Applications: Introduction (This article 😅)
- Testing Frontend Applications: Setting up Next.js Application for testing
- Testing Frontend Applications: I'm confused, what exactly should I test?
- Testing Frontend Applications: Efficiently handling network requests with MSW
- Testing Frontend Applications: Are my tests enough and solid? Introduction to Test Coverage
- Testing Frontend Applications: Guarding production using our test coverage
For this series I would be using Next.js, however the concepts taught can be used in any framework or even in apps built directly without frameworks.
I hope that at the end of this series you would be able to easily write tests for your applications. Have fun learning!