A fellow reader writes in to say "pls no" in response to my comment that nobody reads tests.
That's [coming up with test cases] much more fun! And rewarding. And it's fine if the tests are slop. Nobody reads those.
Which sounds more controversial than you'd think until you've seen tests people write in the wild. Your fellow reader was right to complain. It can be bad out there.
The tests were slop and hard to understand. I don't know if they were AI-generated or just written by someone who didn't really know how to do it correctly. I ended up deleting them. It was a complete waste of time and the tests provided no additional value whatsoever, because when they did fail, I couldn't tell if it was my fault because I couldn't understand the test's intention (or its interdependencies with tests ran before it... because they built upon previously ran tests with the data changing across them...)
PS: you can read and share this online
Slop does not mean ignore good practices
Okay lots to unpack here. This sounds like an atrocious test suite.
When you write tests, AI slop or not, they should follow best practices:
- test the outcome, not the implementation
- name tests based on intent, not what happens
- make tests independent
- use shared fixtures or factories to set up data/state before tests run
- typical code needs integration tests – unit tests are for small algorithmic leetcodey functions
- use the type system, don't try to use testing to do the job of types (super common)
- avoid mocks and let your system do its thing. Mock the current timestamp, not the response of a function you wrote.
Name your test "Given X, Y, Z, when user does B, then Blah". Then test that Blah happened.
Think about test cases, not the implementation
Coming up with combinations of X, Y, Z, B, and Blah is interesting and important engineering work. It's okay if those tests are repetitive and follow the same pattern:
-
set up X
-
set up Y
-
set up Z
-
call B
-
test Blah
-
set up X
-
set up Y
-
set up Z
-
call B
-
test Blah
...
You're going to have dozens of tests that look almost the same. For different combinations of X, Y, Z, different values of B, and Blah. Use AI to help you write these. Make them even more obvious and repetitive than you think is reasonable. It's going to look like slop. That's okay.
The worst you can do is look at the repetition, get annoyed, and write an abstract hammer factory factory method that iterates through the combinations and runs a super awesome abstract test that can test almost anything. I've done this. It's a trap.
It's better to have more tests that are straightforward and easy to understand, than fewer tests that use magic. Focus on intent and make it obvious.
Be clever in your code. Keep tests simple. And if you're really worried about how much set up your tests take, write code that relies less on state and more on inputs. 😉
Cheers,
~Swizec
PS: don't be too clever in your code. You have to be twice as smart to debug your code than you were writing it.
Continue reading about What I mean by "tests can be slop"
Semantically similar articles hand-picked by GPT-4
- Why you shouldn't use AI to write your tests
- AI writes good tests, actually
- You don't need tests
- re: The Industrialization of IT
- Different worlds
Learned something new?
Read more Software Engineering Lessons from Production
I write articles with real insight into the career and skills of a modern software engineer. "Raw and honest from the heart!" as one reader described them. Fueled by lessons learned over 20 years of building production code for side-projects, small businesses, and hyper growth startups. Both successful and not.
Subscribe below 👇
Software Engineering Lessons from Production
Join Swizec's Newsletter and get insightful emails 💌 on mindsets, tactics, and technical skills for your career. Real lessons from building production software. No bullshit.
"Man, love your simple writing! Yours is the only newsletter I open and only blog that I give a fuck to read & scroll till the end. And wow always take away lessons with me. Inspiring! And very relatable. 👌"
Have a burning question that you think I can answer? Hit me up on twitter and I'll do my best.
Who am I and who do I help? I'm Swizec Teller and I turn coders into engineers with "Raw and honest from the heart!" writing. No bullshit. Real insights into the career and skills of a modern software engineer.
Want to become a true senior engineer? Take ownership, have autonomy, and be a force multiplier on your team. The Senior Engineer Mindset ebook can help 👉 swizec.com/senior-mindset. These are the shifts in mindset that unlocked my career.
Curious about Serverless and the modern backend? Check out Serverless Handbook, for frontend engineers 👉 ServerlessHandbook.dev
Want to Stop copy pasting D3 examples and create data visualizations of your own? Learn how to build scalable dataviz React components your whole team can understand with React for Data Visualization
Want to get my best emails on JavaScript, React, Serverless, Fullstack Web, or Indie Hacking? Check out swizec.com/collections
Did someone amazing share this letter with you? Wonderful! You can sign up for my weekly letters for software engineers on their path to greatness, here: swizec.com/blog
Want to brush up on your modern JavaScript syntax? Check out my interactive cheatsheet: es6cheatsheet.com
By the way, just in case no one has told you it yet today: I love and appreciate you for who you are ❤️