Why have automated (unit) tests?
- You don’t have to swing around the whole stack to develop something.
1.5. You are already manually testing your app when you ship code. There are compelling reasons to automate that too. - It forces us to understand the code we are using and how it interacts with the other parts of the system which results in fewer bugs.
- It can document intent.
- Easy-to-test code often is sometimes easier to understand and has better design in regards to separation of concerns.
- I guess catching regressions are nice too. (I put this last for a reason.)
Remember, you are always at least manually testing when you develop code.
I watch developers change code, refresh the page, go to a dropdown, type something in to a search box, click on a control, select an item in a list, and then FINALLY invoke the thing they are developing. This is so exhausting and cumbersome. I'd rather hit save on my IDE and watch my unit test run and give me FAST feedback of whether my code works.
It's not quickly reproducible either.. sure, the developer gains some muscle memory about how to quickly set up the database state and run through those motions but what happens when another dev (or themselves) comes back to it in 8 months?
... Do we really want to launch a database, upload a photo, just so that we can develop the part that lets us comment on a photo? No. Lets engineer the code / tests so that we can verify something useful about that without swinging around an e2e situation.
The concept that I keep thinking about is that we always have to at least manually test our code. Which is launching the app, opening the browser, clicking around, and then with our brains, we see how it is working or not working. Then we edit code and hit refresh (or HMR) until the feature is ready to ship
1.5 You are already manually testing your app when you ship code. There are compelling reasons to automate that too.
We always have to at least manually test our code. Which is launching the app, opening the browser, clicking around, and then with our brains, we see how it is working or not working. Then we edit code and hit refresh (or HMR) until the feature is ready to ship
Problems with this:
-
So much of that process is stuck in our heads. Other devs (and our future selves) have to come back to learn/test all these test cases we do manually.
-
It is slow in the aggregate to manually test especially when rewriting and to point (1).
So how do we begin to fix those problems: we write code to test our code, ship the tests along with the product. Something to think about when answering the question: which tests and how many tests should we write?
If your UI Component is 'simple' and accessible (via harness) then we don't have to necessarilly use a unit test runner... we could use something else like Storybook. I think this could be an adequate replacement for unit tests (in some cases) because we can rapidly set up and test scenarios in an isolated environment.