✅ AssertJS 2018 Passed the Test ✅
I just got back to Gainesville yesterday, and I’m still riding my high from all the great talks I saw and all the great people I met.
In case you missed it, here are some points you need to know about the state of the JavaScript testing world:
👉 Lots of smart people have conflicting opinions 👈
Someone new to testing may have came to Assert(js) Testing Conf looking for the one-size-fits-all solution to testing, but what the conference reinforced is that there are many ways to test your JavaScript, each with its own set of upsides and downsides. This isn’t a bad thing though. In fact, it’s beautiful!
Some of the presentations reiterated common truths to testing:
- Arbitrarily striving for 100% coverage gives you diminished returns on your time and effort (unless those edge cases could cost you a lot of money if left untested).
- End to end testing has historically been a complete nightmare for front end developers. (Not anymore! I’ll hit on this later)
- Testing culture comes from within. Everyone has to be on board, from the leadership to the developers. Any reasonable engineer will tell you tests are important, but when push comes to shove, team members need to hold each other accountable and make sure to test the code accordingly.
- Testing has a sizable cost up front, but returns a lot on that investment in the form of allowing the team to ship code with confidence and not chase their tails fixing bug after bug.
On the other hand, a few of the opinions expressed during the presentation really blew the door off the hinges in my mind on how I should be thinking about tests. I am definitely questioning some of the traditional values I learned back years ago when I wrote my first tests.
🤔 To Mock, Or Not To Mock? 🤔
Justin Searls had my favorite presentation of the conference — a machine gun salvo of slides (725!!! 😅) revolving around the idea of mocking. The presentation isn’t up on YouTube as of the time of me writing this, but when it is I highly encourage you to go watch it. The presentation really made me question my perspective on the fundamental use of a mock.
One great point he made — either mock your dependencies fully or don’t mock at all. No half measures. Mike Ehrmantraut would be proud.
🏆A New Gold Standard: The Testing Trophy 🏆
Historically we have used the “Testing Pyramid” as a point of reference when thinking about testing priority. The technology around us has changed quite a bit since the construction of the pyramid, and it may be time to reassess how we look at testing priorities. Check out Kent C. Dodds’s take on it now — The Testing Trophy!
Static checks such as Flow and ESLint should be the first line of defense on catching problems in our code, and can be ran before a contributor even commits a change. Integration tests give the biggest bang for our buck, and should be prioritized accordingly. Unit tests can fill in the gaps, and E2E tests can confirm the happy paths of your app are still fully functional.
🎓 What If I Told You All Tests Are Integration Tests? 🎓
In my eyes, the most thought-provoking opinion expressed was Gleb Bahmutov’s take on the essence of a test. As technologies around us are improving and our processes are changing, the lines between unit, integration and e2e tests have been blurred.
Historically we’ve looked at integration tests as tests that touch many parts of the codebase and make sure those parts are working together as expected to achieve a goal.
Couldn’t the same be said about E2E tests? It’s hard to argue that E2E tests are so different from integration tests enough that they warrant a whole separate category. Really, at a high level, the only difference between the two historically has been that one runs in a virtual DOM and the other runs in a browser.
With tools like Jest out there, writing integration tests have moved from being a chore to a pleasure. On the other hand, E2E tests are hard to write, and even harder to maintain. The technology just hasn’t kept pace with the changing ecosystem around it. Back at my days in FanDuel, it wasn’t uncommon to have to rerun a Jenkins build multiple times per commit since a random Selenium/Protractor test would fail here or there. It was almost not worth the trouble of having these tests because of all the time we spent keeping them afloat.
Even with all that, I do have to say the future of E2E testing is looking really bright thanks to an amazing piece of software that Brian Mann presented on…
🔥 🔥Cypress.io is a game changer for E2E 🔥 🔥
It’s been a while since I’ve been this excited about a piece of technology. Before this conference, I hadn’t even heard of Cypress, and now I’m itching to get it up and running at Feathr and get going on writing some tests.
What is Cypress? It’s easy to compare it to Selenium since it runs end-to-end tests in a browser like Selenium, but it’s so much more than that. Cypress has an entire UI built into it for dissecting your front-end application and figuring out where the points of failure were. It has an amazingly smart engine under the hood that understands things about your app that Selenium could never do (never do well at least…).
No more Selenium wait-some-arbitrarily-long-amount-of-time hell on every async call you were accustomed to before — Cypress knows when to move onto the next command by monitoring the network calls that are pending. Cypress can also do interesting things with local storage and cookies to set your test up in interesting states before the test even runs. During the presentation, I even saw an example that imported an arbitrary React component and tested that in isolation from the rest of the app, which blew my mind. As I mentioned before, the lines between integration and E2E tests have blurred, and Cypress is part of the reason why that is true.
👏 OK Grow Knocked The Ball Out Of The Park! 👏
It’s amazing that this was the first year of AssertJS. The folks at OK GROW! ran this event like seasoned veterans, and the conference went on without a hitch. I truly don’t have anything remotely negative to say about the show. Thanks a lot everyone for all your hard work on this one!! If you can’t already tell, I’m super stoked about next year’s show.
