Teaching Testing: Our Testing 101 Materials

Posted by on August 20, 2014

Etsy engineers have a wide variety of backgrounds, strengths, and weaknesses, so there are no engineering skills we can take for granted. And there are things you can’t just assume engineers will learn for themselves because you throw a codebase and a workflow at them.

I work on Etsy’s continuous deployment team, which advises on automated testing of our code, and I felt that we could use some stronger means of teaching (and establishing as a conscious value) the skills of testing and design in code. To that end, I recently wrote two “Testing 101” materials for use by all Etsy engineers. They’re now both on our public Github: the Etsy Testing Best Practices Guide, and our Testing 101 Code Lab for hands-on practice applying its ideas. Both use PHP and PHPUnit.

We called it the “Testing Best Practices Guide” because we love misnomers. It’s more about design than testing, it describes few concrete practices, and we don’t call any of them “best” .

Within Etsy, we supplement mere documents with activities like team rotations (“bootcamps”) for new hires, technical talks, and dojos (collaborative coding exercises) to practice and have fun with coding topics as a group. And of course, we do code review.

Deeper technical considerations are often invisible in code, so you have to find a way, whether by process, tooling, or teaching, to make them visible.

Posted by on August 20, 2014
Category: Uncategorized

2 Comments

Very nicely written tutorial. It makes a great case for the benefits testing has on API design.

I think it needs a deeper discussion on dependency injection though. Passing dependencies by parameter doesn’t scale. The ServiceLocator pattern could help. It might also be worth linking deeper reading on the principals you cover.

    Thanks for your comment. Dependency injection frameworks work and people should generally know about them, but we figured we could introduce the basic principle in terms of plain modularity, and people can decide down the road how best to manage configuration for a specific project. Or in other words, we stuck to basic principles at the expense of everything else.