The letter S in a light blue, stylized speech bubble followed by SpeakBits
SpeakBitsThe letter S in a light blue, stylized speech bubble followed by SpeakBits
Trending
Top
New
Controversial
Search
Groups

Enjoying SpeakBits?

Support the development of it by donating to Patreon or Ko-Fi.
About
Rules
Terms
Privacy
EULA
Cookies
Blog
Have feedback? We'd love to hear it!

How to write better unit tests when there are none

graphite.dev
submitted
a year ago
byjosephtoprogramming

Summary

When I joined Graphite, there were almost no tests in the entire codebase. The dirtier the tests, the harder they are to change. The more tangled the test code, the more likely it is that you will spend more time cramming new tests into the suite.

The mergePr method is used to test whether a PR can be merged with another PR. The code has a lot of boilerplate and is hard to read. I’ve now refactored it to separate out the logic from the side effects. This makes it easier to understand and test.

The Graphite team has been working on improving the way we test PRs. One way to do this is to use a domain-specific language. Another way is to change the way the test is written. We hope this article will help you with your own tests.

Consider the following set of checks which assert that an array contains two entries, PR #42 and PR #500. If the entries array returns three items instead of the expected two, the test will fail. An engineer would likely start by modifying the test to then output the list of returned entries.

 analog clock street sign comic book wall clock-0
13

4 Comments

2
practicalmagic
a year ago
Always shocks me a bit how much tests are neglected by most devs
1
josephOP
a year ago
Always viewed as a delay instead of a benefit, convincing product owners is always a pain.
1
justadev
a year ago
Make the underlying code better is such an underrated feature lol
1
joesch
a year ago
Like the other AI post that was here, this is a good usecase for AI to generate them and then give a pass here to fix your own code.