Gearing up for Assert(js) - an interview with JavaScript testing experts
Blog

Gearing up for Assert(js) - an interview with JavaScript testing experts

We’re getting ready for Assert(js), the first ever conference focused on testing for JavaScript developers, and we’ve got an amazing list of speakers lined up. They have already sparked a few conversations on Twitter, so we decided to get a panel together on the HashBang Show to give a preview of what the conference has in store!

The panel included:

We covered a lot of testing-related topics, both general and JS-specific. Tune in to the episode below, and scroll down for discussion highlights and more details on the conference!

Here are a few highlights:

The origin of mocks / test doubles

Justin had an interesting bit of history on the origin of mocks/spies/proxies/fakes/test doubles:

  • They were first introduced in the late 1990s by members of the London Extreme Programming Group.
  • People like Steve Freeman & Annette Price introduced them as a mechanism for exploring legacy code.
  • “Imagine a big legacy code base as the Death Star, and you would pass in a mock object as a tripwire and whenever it was interacted with in any way it would explode.”
  • This was a way of informing them how the argument was being interacted with by the “unknown, confusing subject under test”.
  • London XP group people continued using test doubles as a way of getting design feedback when using TDD to design a new system
  • … and this is where a great discussion ensues about how they’re often misused.
  • Justin recommends reading Growing Object-Oriented Software Guided by Tests by Steve Freeman and Nat Pryce

The “test pyramid”

  • The test pyramid is the concept that the automated tests should mostly be made up of unit tests, which form the base of the pyramid, then less integration tests, which form the middle, and only a small number of end-to-end tests which drive the UI.
  • Kent: Write tests. Not too many. Mostly integration.
  • Gleb: The shape of the pyramid is not really determined by our needs, but it’s determined by the tools we have now.
  • “Confidence increases as you go up the pyramid”, but convenience decreases.
  • But Justin has an alternate view: he finds that, counter to what most people expect, pure unit tests which mock everything in isolation actually do provide high confidence. His reason why is that, as explained in this article, unit testing is “encoding thoughtfulness”, and this results in a more high-quality system being built.

    “Tools and workflows that maximize intense thoughtfulness tend to embed and encode our desires of what the system should do effectively… and this is why I tend to encourage people to not over invest in automation tools, especially record/playback tools because if anything they select for thoughtlessness”

  • Brian on end-to-end tests:

    The failure of end to end testing is: when there is a prerequisite [for the state you want to test], you then use the UI to generate the state for another prerequisite, and that’s basically where it all goes wrong… If you’re testing the shopping cart functionality, do you use the UI to visit the admin area to generate 100 products to then add those products to the shopping cart? Absolutely not. What we recommend is this: you have a few unmocked, unstubbed integration tests that test the really critical areas of the application. And once you’ve done that, once you’ve established that that works, you have 100% confidence, you never use that part of the UI ever again. That is basically the philosophy of Cypress and that’s what makes it a very different tool because architecturally it enables you to do stuff like that”.

What’s different about testing in JavaScript

Testing asynchronous code:

  • The tools we have now in recent years have improved testing async a lot, e.g. promises and async/await.
  • A lot of the reason for async code is I/O, which should live at the periphery of the application, but the “meat and bones” should be business logic, and to segregate the two is really beneficial.

What to look forward to

The panelists are looking forward to meeting and talking with attendees about their testing approaches and challenges. We encourage everyone to take the opportunity to talk to all speakers in what will be a small and social environment. So come to San Antonio and hear more about the topics covered this episode over drinks and food!

Reminder if you missed the special promo code announcement by Robert:

Use the promo code HASHBANG on check-out & get 20% OFF the regular ticket price!

For tickets and conference info, visit https://www.assertjs.com/

We hope to see you there!

We'll share what we've learned, get tips and info in your inbox occasionally