Test Driven Learning
I love test driven development (TDD) and lately I’ve had a need to re-learn groovy scripting for CI pipeline customization. I’ve also needed to learn node.js (and npm) as well as Python. Can I not apply test driven development to learn new languages and tools? Yes! Here’s how I did it.
Firstly, you need to learn the unit testing tool(s) available for the language/platform you’re going to learn. If you like books, this means skipping to the last chapter or worse, the appendix, to learn how to write unit tests for the language. Note to book authors: put the unit testing chapter nearer the start of the book.
Once you have your IDE/editor project set up, you can begin writing tests to learn (via verification) the language. Putting your tests in a side project is much better than putting them into the production project where you shouldn’t be unit testing the language, platform, or libraries. Production project unit tests should only be testing your code.
You don’t have to exhaustively test all language aspects. Just write a test for the part you need to learn right now. That’s how I started my groovy-learning project. We use Groovy to extend our build pipeline, and each time I began to struggle how to do something in groovy, I’d create a new test. Groovy regular expression functionality is a little strange. JSON and YAML handling are a little more intuitive with Groovy’s builder functionality. Loading Groovy classes via a file to be used in a Groovy script was fun to write. This was needed for some non-pipeline tasks I needed.
In addition to re-learning Groovy, I got to use Spock – Groovy’s excellent test framework. I also wanted to learn Gradle. So I set the project up with it instead of Maven which is my standard build tool. I’m still on the fence regarding Gradle for reasons too long for this blog post.
My latest efforts have been focused on Spring learning. In this case, in addition to learning the various Spring modules, I’m also focusing on deciding things like:
- the best way to name a test method so its purpose is clear
- are MockMvc and TestRestTemplate tests unit tests or integration tests?
- hint: they’re integration tests by strict definition, but does it really matter if you aren’t duplicating tests?
- FYI: I duplicate tests a lot in this project because… learning.
- how to set up Maven to segregate integration tests from unit tests?
- how can I use testcontainers (which is not Spring) to assist with automated testing?
To summarize, I’ve adopted test driven learning to force myself to write tests thereby cementing the concepts in my head. Something which reading a book or web page doesn’t do. I save the tests in git so I can refer to them later if I forgot something.
Will “TDL” become a thing?