Duped

You are watching a conference video, coding along with a tutorial, or attending a live event where the presenter quickly scaffolds out a project to demonstrate the fundamentals of some framework. There is a high probability that it is a ToDo application. Right at the end, if you're really lucky, the presenter will mention testing, and it will sound something like, "Let's write some tests for our nifty little app. You'd probably want to use Test-driven development (TDD) and write these tests first."

That has been my experience the majority of the time. I've even bought online courses that make promises like learn to build Angular the TDD way, and those courses actually focus on the testing framework instead of TDD. Most of the time the application is already working, and the tests are written at the end.

Learning how to use a testing framework is less important than learning how to write tests.

It's a Process

Writing tests isn't about whether you prefer Jasmine's built-in assertions or Mocha's assertion-agnostic approach, to name two of the many, many testing frameworks. Writing tests is about asking questions.

What kind of questions?

Good question. 😏

Once you've wrapped your head around the steps for TDD (paraphrasing, write failing tests, write the code that is being tested until those tests pass, refactor/make improvements without breaking all the tests), you'll be left wondering what exactly you should be testing. I loved growing up with Angular, but the early documentation on testing left me disappointed. Do I really need to ask my component if the title I typed into the <title> tag is correct? Yes. No. Maybe? It's truly up to debate, and you'll find the answer only comes through experience with a much broader range of topics such as behavior-driven development and domain-driven design.

I believe we are all living our lives according to our own programming.

My unsolicited advice: just get started! A brief aside here … maybe you are green-dominant like me, and you feel like you have to have everything in place, all the knowledge, all the information before you can start something. In the process of learning about myself, this has been one of my greatest discoveries because it has prevented me from taking action in the past. Knowing my tendencies helps me to propel myself forward when I am stuck in an old pattern. Also, there are just as many testing frameworks for personalities as there are for code. I'd say that is pretty remarkable, but I believe we are all living our lives according to our own programming.

In my next article, we'll do exactly that by getting started with some testing/questions to ask while building your API. You'll see that building something new isn't just sitting down at the keyboard, grabbing a few things from your package manager, and just sticking them together until you figure out how your project is going to be designed. We'll start with the questions.

While writing this article, I popped over to GitHub and found this curated list of TDD resources. While I am losing an entire day diving down that rabbit hole, I'd love to hear about your favorites in the comments!