Every developer has mixed feelings about writing tests, some think it's for the testers to do, some would like to avoid writing these at all costs and some would judge you if you didn't write any.
Then there's people like me who know that you cannot be on one point of the spectrum in this case, tests are important for every software but there's also a time, place and project where tests are to be written.
We are going to go through the tools I use for tests and when do I take writing tests seriously.
Let's start with tools cause that's going to be a really small set compared to the mentality part.
Most test suites come with everything packed but then there's others where the test runner and the assertion is taken care of by 2 different packages. We've had Jest in the JS community for a while, which takes care of everything for you but I don't really go with the whole batteries included setup for anything other than survival gear.
So, I use a combination of Mocha and Chai for most of my testing, I have used Ava for certain cases but it's mostly mocha and chai, older setups I had used Karma but I've not worked with it in like the past few years.
As mentioned, it's mostly Mocha and Chai and Chai comes with an added plugin of chai-http which is what I use for testing the API's.
I'm not a TDD person, i write tests mostly after I'm done with the actual base API and not write the fail cases first and then write the feature next because most of my workflow depends on an incremental and iterative approach to the solution, so the TDD is more like torture in my case. Works well for people who do work on stricter paths, just not for me.
This is a hard part, testing every click and action for a web app can be time taking and has sometimes taken longer than the acutal implementation and so I just setup the tests to check for renders instead of everything. The other stuff
So I use snapshots of the render, a concept I picked from
Sindre where you can render the component
using react-test-render and then test if the needed props are making the
needed change in behaviour. This can be hiding/showing based on a prop,
rendering a certain prop in a certain element, changing a certain state or
triggering a certain prop.
Considering the atomic nature of how react components are written , this takes care of almost everything that could break. The only thing that remains is the business logic, which can be simple functions you export from helper packages and then test them as well.
This blocks most cases of failures.
You can obiously check event handlers as well but as I said, I prefer doing them manually.
This is for react, I've not tried testing setups for other UI libraries or frameworks but my approach would be similar if I did.
There's quite a few people that consider that everything should have tests or that makes you a bad developer.
In that case, I am a bad developer.
But then , I'm not going away without an explanation(should already know that by now).
I say the decision of writing tests depends on a few factors
If the requirements you are working with are variable in nature, i.e. if they are bound to change at variable points in the development cycle then writing tests is going to be a huge waste of time as the tests may or may not get invalidated as you go through. Still once you see a certain requirement is going to stay for longer, it's preferrable you write a test for it as the other changes you make over time shouldn't break that requirement.
On the other hand if you are clear in terms of what you are building and what the end product is going to prioritise, you are better off writing tests to maintain that stability and reduce the manual load of checking trivial stuff.
This is pretty self explanatory, the lower the time you have, the less you need to focus on tests because if you don't have something to test in the first place, the test scripts make no sense.
Is your project a simple single functionality tool? You don't need to write tests but that doesn't mean you don't have to, you can go ahead and write a test if it's a small thing and it builds up to a being a good habit later.
If your project is a prototype that you will throw in the trash right after testing the concept you had in mind, then the test is totally unnecessary though there's a but in this case. Like if you are going to keep building on that prototype to be the final case, write a test for it before you add in more features to it.
I don't mind tests as they reduce your load and that's good, since you don't have to keep confirming things that should be already working, and this saves you from the whole Don't deploy on a Friday night to a limit, cause the test coverage is going to fall short to a certain percentage every now and then but if you can avoid the majority of setbacks it still gives you a lot of peace of mind.
I can say that considering I've had TillWhen deployments fail and save me a few times.
That's all for now,
Adios