This post was originally published on January 25, 2021 on my blog.
Pssst! I send weekly newsletters about the self-taught coding journey and my own coding adventures (and misadventures!) Sign up here! >>
Today I spent two and a half hours pair programming with a teammate who really helped me with a big (for me) refactor and walked me through a session of writing tests on an accompanying spec (or test file).
We covered the basics of Test Driven Development (aka TDD, and also something I feel like you hear about all the time as a self-taught developer, but literally never have the opportunity to learn or use, so I’m grateful to be learning about it now).
Basically, you need to write a test before you even write your function, and you need to get the test to pass by the simplest means necessary. Like, really basic “get the function to return true by literally returning true in the function” kinda thing.
Once your tests are passing, that’s when you can go ahead and start widening the scope of the function by writing another test to check and then writing the corresponding code to ensure that that part of the test passes.
Interesting stuff and definitely something new to get used to!
In any case, I can see how powerful it’ll be as I continue to use it, but for now, I need to keep practicing and writing tests.
Oldest comments (2)
TDD is great, but it can become tricky in huge projects... There a lot of content online talking about it.
yeah this has been my experience too. I find that I have to spend a lot of brain power on maintaining the test suite. instead when I focus on the features first I find that I write beautifully architected and scalable systems. good thing my team has a dedicated person to write integration tests before any feature reaches the staging/uat whatever.