Back then, when I got promoted to the primary frontend department, I needed to learn unit testing. I was nearly all by myself. All that I got were some examples scattered through our application. It wasn't too big of aid, though. Every single developer wrote tests differently. Furthermore, the developers that seemed the best back then didn't write tests at all. Because of that, I didn't have much guidance.
Learning the bad way
These times we were during our transition from AngularJS to newer versions of Angular. These two frameworks felt very similar about the testing.
The basics that I got to know seemed pretty effortless. You have a component that has methods. Use them and check whether everything is working as expected. The mocking was a much more complicated part. I learned to insert mock versions of dependencies to test components standalone. Sometimes it was time-consuming to do it properly and then to maneuver all of the mocks in tests.
That approach sounded sensible to me back then. I was thinking, "I want to test the unit. It's called unit testing for a reason".
Way of the mocking
When I got my hands on the newer version of Angular, I felt that mocking is even harder there. Of course, some schemas let you don't mock the components. Still, there are all of the services, directives, etc., it was too much to handle.
The problem was that there weren't more developers that cared about tests except for me. So I was all alone on my road. No one could tell me to stop the mocking part. Moreover, I looked for solutions that would make it easier. Somehow I stumbled across the "ng-mocks" library. It lets you mock anything in your tests with little to no effort. Of course, it's wondrous when used sparingly. The problem was that I used it for basically everything.
Light in the tunnel
The turning point in this story was my experience with Svelte. I enjoyed the framework, and it seemed promising for me. Somehow I convinced my supervisors to use it in my big project at the job. Naturally, I was supposed to write tests for my code.
Same as every developer would do, I just googled how to write tests in Svelte. That was how I got Testing Library in my hands. Firstly, it felt so wrong. If I can't access my component methods, how am I supposed to test them? I wrote some tests, even though it didn't click for me. I didn't write many of them.
After getting back to Angular, I started to see problems with my testing approach. And at this point, it wasn't just my approach. Everyone at the company followed me. Tests broke because methods got renamed, dependencies changed. Moreover, I started to feel the uselessness of these tests. They didn't help me to prevent bugs. They got annoying at some point.
The one thing that completely changed my mind about the testing and Testing Library was this particular talk. After watching it, I was speechless. I was sure how I should write the tests from this point. I should write tests to resemble users of this part of the code.
Testing Library
Testing Library makes writing such tests a breeze. It simplifies user and developer interactions and makes it easy to test them. Moreover, I started to feel that all of this makes sense. Tests begun to broke when something got broken.
Furthermore, it clarifies many things that I always had problems handling. Asynchronous paths of my code were always scary for me to test. I never could find a way that felt right. Library shares API made just for this. Besides, its opinionated style is always guidance when I don't know how to do something.
The right mocks
Of course, sometimes you need to mock something. You can't afford every test to hit real API. The talk which I mentioned previously showed me why and what we should stub sometimes. Testing Library was a helping hand there as well. It has recommended way of mocking the backend part of your code. Mock Service Worker is a library perfect for that.
And that's where I'm with frontend tests right now. All I learned and all of my mistakes. The most unfortunate thing is how long it took me to spot the stains on the mock armor that I made. I hope you enjoyed the story, and see you again!