If you have not recently picked up Test Driven Development (TDD), then you should stop reading here and buy the book Clean Code by Robert C. Martin (My default spoiler for new developers I meet).
Recently, a number of developers found out that TDD is not only good for test-driving your own code, but also for learning new languages and APIs.
It’s just simple. For any new API or language, create a new project, pick the latest and greatest unit testing framework and start writing unit tests until you find yourself familiar with the language and its API.
I learned about test-driving new APIs by the need to map project requirements to the exact semantics of specific APIs. APIs (especially those from the big players) are not always documented in the detail you would expect them in, and researching the various Q&A sites or putting up a question at StackOverflow involves investing a lot of time and a lot of distraction.
Often, the semantic details could be nailed down to a simple unit test and so I found that writing a unit test is mostly a better and faster way to find the hidden truth behind the often confusing semantics of APIs or languages. Moreover, the tests persist and can be useful in retrospect to find out about the rationale behind consequential design or implementation decisions. These tests may even be considered as part of the design documentation.
I think that TDL needs a lot more attention and should be used in companies and universities to propagate a more pragmatic learning approach.
If you’d like to learn more about TDL, follow these links:
I hope you like this blog post, comments are welcome!