Building the library: TDD and static type checking - adamvinueza/libtrace GitHub Wiki

tdd

I wrote an earlier version of this library quickly, and wrote the tests as an afterthought. Because I wrote it quickly, and hadn't thought through exactly what I was trying to accomplish, I did some things I regretted later, and that I didn't know quite how to walk back. So rather than pawing clumsily through the repository and doing a bunch of painful refactoring, I decided to start from scratch, but this time use a test-driven-development strategy to help me focus more on what I wanted the library to do.

I've written elsewhere about the pros and cons of TDD. What I think it brings to this project is a way for me to slow down and think more deliberately about how the API should work.

Because this is mainly an exercise, my procedure is to read through the Honeycomb source code, copy and maybe tweak a unit test, then build the code that makes it pass, often peeking at the corresponding Honeycomb source to see the decisions that were made. I've been pleasantly surprised at how easy it's been to figure out why decisions were made.

mypy

Another thing I've decided to do is add type annotations to my code, and I integrated mypy into my workflow to enable static type checking. It's not as if I miss statically typed languages (I still write plenty of Go). What attracted me to mypy is that it allows me to catch subtle mistakes I often miss, and helps "tighten" my code. I've found that I write simpler, cleaner, more Pythonic code when I use type annotations and check them using mypy.