Reading Test Driven Development with Python by Harry Percival, Part 4

Reading Test Driven Development with Python by Harry Percival, Part 4

learning the tdd workflow

Today I finally have some time to proceed to the next chapter of TDD with Python.

Recently I was doing a group project that involves Django and although I really wanted to implement TDD, I never really had the change. My fellow group members (awesome people) have already started and have their own ways of completing the project. Introducing a whole new way of doing things at this point might just slow us down. I (think I) learned that if I were to implement TDD I have to start from the planning phase, this does really doesn’t work out when we are already in the middle of stuff. However I digress.

In this chapter, we map out step by step on what we want in our home.html to do or have: a title for our to-do list app, input boxes, and a table. We do this by writing tests that we know is going to fail, like have a title (although we haven’t written the title in home.html yet), have a heading (also haven’t done that yet), having an input box and so on. Once we run the test, we can see all the failed tests.

In the past, when I see a failed test, I panic.

I don’t look at the test results, I rewrite the test or delete them till I don’t see any failed tests.

Now I see it as a guide on what I need to complete. I take my time and read the failed messages and build my html to match the tests. Once the test pass, we refactor, then test again.

During this process I also learned that I often failed tests because I can’t spell. I failed a test multiple times just because I misspelled the word “table” with “tabel”. Very embarrassing.

At the end of the chapter I think I have the work flow down.

So I sometimes play Magic, the Gathering on my spare time. With Magic, there are phases you can follow (untap, draw, main 1, combat, main 2, end), and now that I know the work flow this becomes so much clearer:

  1. We write a test

  2. Run it and let it fail

  3. We write some code to pass it

  4. Refactor the code

  5. Run the test to make sure it still works

  6. Back to step one.

I enjoy having a process to follow, and this makes me look forward to reading the next chapter soon!