The ThoughtWorks 2024 Radar was released (you can download the PDF with 1 click, no annoying sign up required). Below are 2 things:
- me covering things I’m confused about on Component Testing
- cool new tools to investigate or figure out why they are going from “Assess” to “Adopt”
If you just wanna learn about the cool new stuff to look at, skip my component testing rant.
Component Testing: Adopt
I have lots of questions on this “Adopt”. My current employer has invested a lot of training & tooling around helping teams do Component testing, which I love. What I don’t love is the yet another testing technique who’s definition differs based on who is talking about it.
Lemme outline the few definitions I’ve seen in the wild in the chronological order I learned about them, with what I _think_ ThoughtWorks’ definition is last:
- Storybook to help test React components in isolation, utilized heavily for component framework authors
- testing components in an isolated browser environment using Cypress’ Component Testing
- My latest definition of Cypress Whitebox Testing, meaning all external I/O calls (fetch/xhr, loading JSON, reading localstorage, etc) are cy.intercepted or stubbed/mocked
None of that is the same. A component in the above contexts kind of means a UI component, either something like a or a which composes many other components, code, and CSS. I say “kind of”, because in Storybook and Cypress, you’re using a real browser, not a fake one like JSDom. In this context, I believe using a real browser can suss out a lot of issues, specifically around Acceptance Testing, not Unit Testing. I have the opposite experiences to what they’re citing: you can make Cypress/Playwright extremely fast (using things like it.only, heavy stubbing, designing your UI to be more de-coupled to test specific user flows), and the amount of confidence I have in the application working, for the user, is extremely high. Given Elm’s typing system, this is the primary way you can validate the lack of race conditions in your Elm code, and is nice because you can spend more time writing Acceptance Tests using that tech. Cypress whitebox tests are NOT flaky; they’re deterministic af, that’s why we all love them.
However, I do acknowledge debugging can be challenging. Just because you’re “in a browser” doesn’t always give you extensive insight into why something broke despite breakpoints, debugger keywords, the compiled source code, insight into network calls, and various logs all at your disposal (not tongue in cheek, even with all that you can still be like “dude, why isn’t this working…”)
Next, both ThoughtWorks and Cypress cite “end to end” tests. The definitions here are also muddy. Here are a few definitions I’ve seen:
- Dave Farley’s e2e take, which is basically validating “all the things” work together (not to be confused with a push for early All Up Testing)
- Cypress’ Blackbox Testing, where you do NOT stub/mock ajax calls and other I/O, and this just tests “your site and its integrations”
- ThoughtWorks appears to be saying Playwright/Cypress/Selenium are primarily e2e tools where I view them as Acceptance Test tools, with the exclusion of Cypress Component Testing functionality which mirrors Storybook a bit
- Hillel Wayne calls ’em that too
Finally, I’ve never enjoyed React’s component testing extensions. They are heavily mock / side-effect infested, and heavily encourage you to whip out JQuery skills to validate “My component is rendering correctly” which that doesn’t always equate to “working correctly”, feels like breaking abstraction, and testing if React is working. Instead, whether React, Angular, or Elm, I’ve always felt testing your code works, creating primarily pure components, and testing the “Smart Components” (e.g. components with side-effects) you validate in Acceptance Tests (Cypress or Playwright).
JavaScript web devs have varied opinions, and various definitions of words. That’s generally fine, but as someone who had ThoughtWorks as a young adult hood hero, constantly recommends Martin Fowler and other ThoughtWorks written works as wonderful recommendations to learn, and event wanted to work with them someday… you can see why this completely opposite viewpoint is giving me a crisis of faith.
So:
- agree with component testing in various forms
- disagree with JSDom and “assert my component’s list item 2 has a bold tag with innertext of ‘cow'” in your unit test language of choice.
For what it’s worth, the above is nuanced in various languages. Angular and Lit/WebComponents, for example, if you avoid templates having any logic beyond if and switch binding to public component variables, are way easier to unit test and assert side-effects vs. the current frameworks React and others expose. However, Angular and some WebComponent frameworks require verbose setup code that is itself extremely hard to debug, whereas React/Elm the opposite.
Also, I know creating these PDF’s is a herculean effort, and so is trying to summarize anything in tech, so I’m sure I’m just missing gallons of context.
Continuous Deployment: Adopt
It was amazing boomeranging and seeing my CEO talk about this in his yearly talk. I know event attempting Minimum CD can be a huge change for people, but it’s the best way I’ve seen in working, so good to see it obviously called out in Adopt.
Golem: Assess
I was super pumped when the Zio creator had a hand in creating this State-Machine-That-Can’t-Crash as a Service, called Golem. I was further excited because they had support for Grain, an OCAML style FP soundly typed language. I could just never find the time/inspiration to play as I still feel trapped in the “all things are AWS” vortex. Yes, I’ve played with & used CloudFlare in production, but… as a AWS Step Functions fan, this seemed like a cool idea. One of these weekends I’ll try again with TypeScript since Grain appears to be no longer an option.
Bruno: Adopt
A lot of these REST Clients, some built into VSCode, are getting blocked by various companies because they host your internal API details on their servers or post details to other places. Things like Postman and Insomnia and others have started requiring subscriptions despite claiming they don’t which just makes things worse. So there is a huge push to find similiar tools which don’t share your data. Bruno is one I need to check out since I’m no longer allowed to use ThunderClient.
Visual regression testing tools: Adopt
There are various ways CSS can break your entire application, and there is no way to easily unit test or acceptance test your way into preventing that. I really struggled with early React snapshot tools, and felt the ROI wasn’t there for smaller sites given the numerous false positives. Tools like Applit and BackstopJS are some of the many, including services, to validate your site looks and works ok. They often run after, or at the same time, as your acceptance tests in your pipeline. I’ve got maybe 5 minutes experience with Applit tools, but definitely want to check out Backstop.
GitButler: Assess
The one I’m most excited about is GitButler. As someone who hates Pull Requests after experiencing Trunk Based Dev, and being disappointed in the state and abandonment of various tooling around”abstractions over PR’s”, GitButler looks like it could restore my sanity in the context switching to making PR’s of PR’s.
Mise: Assess
Mise is kind of weird because I’ve never had issues with nvm for managing Node.js versions, and pipenv for managing/running Python projects, so curious go give this a spin and see what all the fuss is about.
Mockoon: Assess
I hate mocks. I tend to work in languages which allow side-effects, and with developers who do not follow Pure Core, Imperative Shell. So anything I can do to learn more about my enemy, and how to manage it, is a good use of time, and Mockoon is another one of those mock creators.
Rspack: Assess
Thankfully, I’ve never had to integrate with Webpack. Unfortunately, I’ve been impacted multiple times by _other peoples_ integration with Webpack. Vite was a breathe of fresh air; super fast, and it worked. So it’s interesting to hear of another contender on speed. Vite won not just because of its amazing speed, but wonderful Developer Experience so cool see what happens here with Rspack.
Zed: Assess
Excited to try the Zed IDE despite VSCode having it’s clutches on me, namely because built-in pair programming, super fast speed, and because the Roc lang creator joined their team.
Pkl: Trial
I was first turned onto Pkl during my Dhall Trough of Disillusionment phase (Dhall is cool, but man is it hard) by James Ward. It looked to be a language that had enough types to compile YAML/JSON configuration files wayyyy more safely. I’ve had enough YAML/JSON misconfigurations break production, that I started looking into ways to compile those problems away, and Dhall helped a lot, but the learning curve and compiler errors are brutal to work through, and I never got excitement amongst peers. Hoping Pkl makes in-roads here.
Conclusion
Be sure to download the PDF yourself, as I’ve ignored a TON of new and existing tech on there (LLM’s, infra, data science) that I find boring, but others may find compelling.
Top comments (0)