Hey there, this is Simpler Machines, a newsletter about Nat Bennet that's usually kinda-sorta mostly about software.
180 of you are getting this e-mail this week. Can we get to 200 subscribers by the end of the year? If you reading this but haven't subscribed, sign up now to get these e-mails a bit faster – it's free. And maybe share this with a friend who'd enjoy it?
Some business stats
The pairing course! People bought it! If you missed it last time, buy it now. We've dropped the price from $17 to $10!
These revenue numbers are a little wonky because they cover slightly different time periods but you get the general idea.
The part that I'm most excited about is that little bump at the end of November, since we didn't do any explicit advertising that week. Folks are sharing it because they liked it.
It will not surprise you that e-mail is by far our best marketing channel. The conversion rate on Twitter impressions was surprisingly good but it's much harder to get people onto the site from Twitter.
Lots more to do around tweaking & optimizing the marketing.
Frontend testing is hard
Mostly what I've been working on is learning React.
jest.mock. For any given google search you'll get like, five different answers, 1 of which doesn't work anymore, 2 of which are incomplete, 2 which work but are awkward, and 1 which is "the best way" but also doesn't work in your codebase for some reason and isn't the accepted answer on Stack Overflow.
So far my testing opinions are:
- Do test top-level views.
- Don't (usually) test individual components.
- Do fake calls to the backend, ideally by actually providing an HTTP response that the component unpacks, but there are also situations where it might make sense to use a wrapper and fake that.
- Don't automock.
- Do test by hand a lot. You need to be in the application and actually using it to confirm that it looks and feels right.
- Jest is slow. We chose it for documentation and familiarity reasons but I don't think I'd use it on my own projects.
I'm not yet using Cypress or Storybook, and the project I'm on has a strong belief that they're too slow and flaky to be worth it.
What's the "unit" in "unit tests"
Despite that "don't test individual components" opinion. I spent most of my week writing tests for a sub-component of a larger view.
The top level component made a lot of backend calls as part of setting itself up, and mocking all those out was tedious. I took a look and I saw that the behavior I was adding was basically, "when I click on Thing A, it changes, and also Thing B changes." Thing A and Thing B were already components so I squooshed them into one component and got to work.
This let me pass in most of the data as typed thingies (Objects?) and skip all of the "pretend to be a web server" bits.
This feels right to me because I'm able to work on a single test file to add this behavior. The tests are scoped to a level that's basically "the smallest unit where I can test this behavior in human-narrative terms." This behavior then gets included in a larger view, but the other parts of the view don't interact with the part that I'm testing at all.
I'm an infrastructure Morlock, and other assorted React opinions
- State hooks! They're neat. Functional components make sense to me. This would be much harder if I was having to deal with class components.
- Typescript is pretty good but it's really easy to write types that don't do much except get in your way. Compilation is also slow and complicates the build process.
- Writing React components is more like writing Terraform modules than any other programming I've done.
I've also developed a renewed appreciation for just how good the design is on Pivotal Tracker. The project I'm working on uses a lot of modals, and they add a lot of complexity to the codebase. Pivotal Tracker does many of the same tasks without an explicit modal and I can see how it would be much simpler to code.