I really didn’t want to write this, but every good link about structuring unit tests is dead. And I don’t want to hype this too much, but learning to arrange my tests in a certain order was one of the biggest productivity gains in my career.<\/p>\n\n\n\n
This is a \"Code review\" post. This is designed to be copy pasted into code reviews<\/em><\/span><\/pre>\n\n\n\n
\n\n\n\nYou should arrange your test into three distinct sections, AAA:<\/strong> Arrange, Act, and Assert. You’ll also see articles touting four sections called SEVT<\/strong>: Setup, Execute, Verify, and Teardown, but in practice, we never put teardown in the actual tests because then they would only run if the test succeeds.<\/p>\n\n\n\n- Arrange<\/strong> \u00e2\u20ac\u201c Set up the conditions for the test<\/li>
- Act<\/strong> \u00e2\u20ac\u201c Execute the code<\/li>
- Assert<\/strong> \u00e2\u20ac\u201c Verify your assumptions<\/li><\/ul>\n\n\n\n
If you arrange all your tests like this, then every test will looks familiar even if you’ve never seen before, which mean you’ll be able to understand unfamiliar code much faster.<\/p>\n\n\n\n
1. Make the sections obvious<\/h3>\n\n\n\n
The easiest way to convey the three sections is to group the lines into the three sections separated by a blank line. If your test only has two or three lines, you probably don’t need the blank lines, and if for some reason your test is so long that it can’t fit on one screen, you might<\/em> need comments to label the sections. <\/p>\n\n\n\nBad:<\/p>\n\n\n\n
expected = {...}\nuser = {}\n\nstubs...\n\nresult = foo(user)\nassert result == expected<\/code><\/pre>\n\n\n\nBetter:<\/p>\n\n\n\n
user = {}\nstubs...\n\nresult = foo(user)\n\nexpected = {...}\nassert result == expected<\/code><\/pre>\n\n\n\n2. Your first test<\/h3>\n\n\n\n
I like to make my first test case either a trivial case (for pure functions) or the happy path (for request\/response). And I try to get these tests to have zero lines of setup.<\/p>\n\n\n\n
Bad:<\/p>\n\n\n\n
test(\"knight is worthy\")\n user =\n id: 1234\n email: lancelot@camelot.silly.place\n name: Sir Lancelot of Camelot\n favorite_color: yellow # This should be blue\n quest: to seek the Holy Grail\n ...a million other things\n\n assert user.is_worthy()<\/code><\/pre>\n\n\n\nGood:<\/p>\n\n\n\n
setUp()\n user =\n id: 1234\n email: lancelot@camelot.silly.place\n name: Sir Lancelot of Camelot\n favorite_color: yellow # This should be blue\n quest: to seek the Holy Grail\n ...a million other things\n\ntest(\"knight is worthy\")\n assert user.is_worthy()<\/code><\/pre>\n\n\n\n2. Copy paste your tests<\/h3>\n\n\n\n
New test scenarios should be a variation of an existing test; every test starts as a copy paste. This repetition makes your code easy for to read because everything looks familiar! Let’s say we need to check if the user is no longer worthy now.<\/p>\n\n\n\n
One consequence is you’ll often end up with extra assertions. I usually keep them, but it’s a balance. If you’re not sure, I ask myself: “is this assertion relevant to the test name?” <\/p>\n\n\n\n
3. Make the “arrange” section as small as possible<\/h3>\n\n\n\n
Minimize the setup for all your tests. The higher up you can get the “act” section of your test, the more readable your tests will be. Remember that the “arrange”\/setup section is boilerplate, and we hate boilerplate.<\/p>\n\n\n\n
A User<\/code> object may require twelve things, but your arrange section should have none of them. Take advantage of fixtures, before<\/code> blocks, factories; whatever tools you have at your disposal.<\/p>\n\n\n\nBad:<\/p>\n\n\n\n
user =\n id: 1234\n email: lancelot@camelot.silly.place\n name: Sir Lancelot of Camelot\n favorite_color: yellow\n quest: to seek the Holy Grail\n ...a million other things\n\nassert user.is_worthy() == false<\/code><\/pre>\n\n\n\nGood:<\/p>\n\n\n\n
user.favorite_color = blue\n\nassert user.is_worthy() == false<\/code><\/pre>\n\n\n\nIn the “bad” example, it’s not clear why this user fails the worthiness test. The reader is expected to compare it to a good example or to know the data. On top of that, it’s many lines before we actually get past the boilerplate. In the “good” example, it’s clear that the user has the wrong color.<\/p>\n\n\n\n
Places this doesn’t work<\/h2>\n\n\n\n
You’ll be able to split up tests into these sections almost every time, but there are some common exceptions:<\/p>\n\n\n\n
- Events<\/strong>, when you need to set up assertions
.on('end', () => { assert ... }<\/code> as part of the test setup<\/li>- Catching exceptions<\/strong>, you’ll be able to arrange in AAA order, but you won’t be able to add line breaks.<\/li><\/ol>\n\n\n\n
Better articles about this subject:<\/p>\n\n\n\n
- http:\/\/www.agile-code.com\/blog\/the-anatomy-of-a-unit-test\/<\/a> (Wayback version)<\/li>
- https:\/\/giang-pham.net\/2019\/01\/07\/patterns-in-constructing-unit-tests\/<\/a> (link is broken)<\/li><\/ul>\n\n\n\n
<\/p>\n","protected":false},"excerpt":{"rendered":"
I really didn’t want to write this, but every good link about structuring unit tests is dead. And I don’t want to hype this too much, but learning to arrange my tests in a certain order was one of the biggest productivity gains in my career. You should arrange your test into three distinct sections,…<\/p>\n Read More<\/span> Code review: organize your tests for your sanity<\/span><\/a>","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"Layout":"","footnotes":""},"categories":[1],"tags":[],"class_list":["entry","author-showmewhatyougot","post-872","post","type-post","status-publish","format-standard","category-uncategorized"],"_links":{"self":[{"href":"https:\/\/www.crccheck.com\/blog\/wp-json\/wp\/v2\/posts\/872","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.crccheck.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.crccheck.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.crccheck.com\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.crccheck.com\/blog\/wp-json\/wp\/v2\/comments?post=872"}],"version-history":[{"count":6,"href":"https:\/\/www.crccheck.com\/blog\/wp-json\/wp\/v2\/posts\/872\/revisions"}],"predecessor-version":[{"id":883,"href":"https:\/\/www.crccheck.com\/blog\/wp-json\/wp\/v2\/posts\/872\/revisions\/883"}],"wp:attachment":[{"href":"https:\/\/www.crccheck.com\/blog\/wp-json\/wp\/v2\/media?parent=872"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.crccheck.com\/blog\/wp-json\/wp\/v2\/categories?post=872"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.crccheck.com\/blog\/wp-json\/wp\/v2\/tags?post=872"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}