You have joined a team with a large codebase and everybody has told you to go and read the code. So you open the main folder, scroll, and close it again slightly more discouraged than before.
Try the test directory instead. It is a better door, and hardly anybody uses it.
A test suite is not a quality artefact. It is a record of what has hurt this team. Every awkward test with the long name and the three pieces of setup is there because something went wrong badly enough that somebody spent an afternoon making sure it could not happen twice. Read in that spirit, the suite becomes a history of the product, written by the people who paid for it.
Start with the names and read nothing else. Test names are a specification in plain sentences, written by somebody who understood the domain, and an hour of reading them will teach you the vocabulary of the business faster than any document. You will also learn what the system is supposed to refuse to do, which is the half of the behaviour that never makes it into an overview.
Then look at the fixtures, the little fake records the tests are built on. Those are somebody's idea of what a real customer, order or payment looks like, and they carry the detail a schema never shows you. Look at what gets faked out, too. Every mock marks a boundary of your system, so the mocks together are a map of who your team talks to and what they assume those people will do.
The gaps are just as informative. The area with almost no tests is either very stable or very awkward, and either answer is worth knowing before you touch it. The tests marked skipped or flaky are arguments the team never finished.
Do not trust all of it. Some tests check the implementation rather than the behaviour and will teach you the shape of the code and nothing about the purpose.
Monday: open the test folder of the thing you are working on, read only the test names for twenty minutes, and write down every term you could not have defined beforehand.
– Asael Shinder
Top comments (0)