It's safe to say that testing in the front-end world has grown over the past five years.
Jest has stolen the scene in the unit testing world, earning over 20,000 stars on Github and being the subject of many popular conference talks.
On the other side, tools like WebdriverIO, Protractor and Cypress.io are popularizing the concept of UI testing.
There are more options than ever for writing tests, and more pressure than ever to have bug-free code.
So why in world would you not write tests?
User testing comes first
There's no point in writing a test if you haven't user tested your site.
When starting clean on a new project, it's incredibly tempting to commit to testing from the beginning. But the most important testing we can start with is user validation of the functionality.
Any test you write will be worthless when the functionality shifts, and it will after user feedback.
So before spending time writing assertions, test your assumptions about the user interaction on your site.
Unclear Architecture
The front-end world is rapidly changing with new libraries popping up on a daily basis.
This leaves many of us starting projects utilizing tools we've never used before.
Writing tests in Jest is not trivial. Especially when starting out.
- How do mocks work?
- What's shallow rendering?
- Do I mock or do I import?
- Should I use Enzyme and Puppeteer and CICD and so on?
It's impossible to answer these questions when you're this fresh to a library.
Instead, take some time to learn what the architecture really looks like. Give yourself permission to write untested code.
Assume you'll be more effective waiting on tests than trying to jam them in up-front.
Opportunity Cost
You're not paid to write tests. Tests only serve the application they're testing. If app is useless, tests won't help.
If you're working on a side project for a tool that no one uses, spending time writing tests takes away from time spent on more important tasks, like getting people to use your work.
Users don't care whether you have good unit tests. There's no difference between an unused tool and an unused unit tested tool.
Let yourself have untested code. Worry about that problem when it actually becomes one.
Finish the system
Don't write more tests when you're not using the ones you have.
If you have 500 unit tests, but never put in the time to integrate them in your build and deployment process, you have 500 useless tests. Writing 500 more won't help.
Your tests should run on every code push. They should run before every deploy. Every developer on the team should see that the tests passed or failed.
If that's not true, then you shouldn't be writing more tests. You should be taking advantage of the tests you have.
Why test then?
They can prevent many stupid little mistakes from making it to production.
They can guide your coding process, helping your write better code.
But there's no good way around the effort tests take to write.
So ask yourself:
- Are unit/UI tests really what's most important at this time?
- Is the project in a good spot for writing them?
- Are we using the tests we already have?
Be honest with yourself and your project.
Tests are like a garden. Don't try planting in the middle of winter.
Header Photo by Isaiah Rustad on Unsplash
Top comments (11)
I agree with the spirit of the post, essentially the best code is the code that's never written. That said, I think we're missing the point to testing: the power it gives us to shape our code by writing our tests before each small piece of production code. In other words, TDD.
I would argue most of the value of tests isn't in validating the that our software still works. That's just a fantastic side-effect. The real point to writing tests is in allowing them to drive the design of our code. TDD forces you to write each function from the perspective of the person calling the function. It doesn't care about implementation details, instead it cares about the interface.
I'm still amazed at the difference in code quality between when I practice TDD and when I don't. It's huge. And the funny thing is TDD usually ends up taking me less time then not writing tests at all, considering all of the time it takes me to debug my untested code.
I totally agree with you. However, I feel that TDD should be used by developpers that are already experienced with the library/framework they're using. The reasoning behind this is that by writing their tests before hand, beginners often end up rewriting their tests when they realize that the library/framework doesn't behave as they have expected. And basically, this takes away precious time that they could have been invested in learning how to use the library/framework better.
This is a great point, thanks for sharing!
Are...are you trolling? Because I am flabbergasted.
I mean, it's one thing to have a healthy discussion around how much testing should be done, or what type of tests should be written, or what parts of an app should be tested. But you are suggesting zero tests. If you are building a prototype for validation, sure that's fine because it's not a real app and people using it know that its not real. But as I read this you are suggesting that people should deploy a production system for real people to use without any tests, YOLO style, because you need their feedback before you can solidify your design. And that is bonkers to me.
I hope to the FSM that your app doesn't do any sort of e-commerce, or authentication, or take user input of any kind.
I don't think Kevin's suggesting zero tests, but rather meant it as avoid pre-maturely writing tests.
Like when you haven't figured out if people want what you are building, don't write those tests yet. I would even say, don't even build stuff before you validated that people want it - you can survey or show people mockups to validate demand first.
Like when you haven't gotten a firm grasps of your front-end stack, don't write those tests yet, because unit-tests like Jest can requires a fair bit of planning beforehand.
And like and when you've got tests that aren't connected to your pipeline, don't write more tests yet. Connect those existing ones first, before moving on the writing new tests.
Yes, this exactly!
Sorry I wasn't clearer in the post. Sometimes I end up having a lot written in my head that I forget to put down in the text.
When I read unit tests I think TDD-style unit tests.
Are those the kind of unit tests you are referring to?
The TDD-style unit tests are not created for the purpose of testing, they are created for the purpose of design. As a byproduct, having a suite of unit tests to ensure basic correctness and detect basic correctness regressions is a nice residual value.
TDD has a very strong stance to avoid writing unit tests pre-maturely. Rather it advocates just-in-time creation of unit tests, and not a moment before.
I'm not familiar with Jest. Probably would have been useful back when I was working in TypeScript.
I love the concept of TDD, but have found it applies more to server-side type scripts than front-end work. For front-end, there's a lot of user interaction embedded in the code, which can make TDD harder to practice (but not impossible).
Some of the most fun I've had writing code was building out a component TDD style. That said, the component had very little user interaction, but a lot of logic going on. It fit the bill perfectly for TDD.
Thanks for the response!
One of the big proponents of TDD is Robert Martin.
Robert Martin does not think user interaction (UI) part of a program is suitable for TDD, as per When TDD Does Not Work.
Just thought you might be interested. ;-)
You are right. I don't even think about writing them, and I have a buggy app for no reason I don't know why.