Python Unit Tests

Yesterday, I wrote my first project from scratch in Python using TDD and it was a pleasure.

The integration of unittests in the Python language took away many headaches that come from setting up an environment in other languages such as C++ or C#. To get started, just import unittest. The next step to configuring is to call unittest.main() from your main loop. That’s all the configuration necessary to start writing unit tests in Python.

When I was writing the tests, I followed Kent Beck’s recommendation to make a to-do list and I really liked how it turned out. The first thing I did was read through some of the documentation and write down different tests I could write. After writing them down, I picked the easiest one out of the list. Moving through the list this way made the work less stressful, not to mention the whole part about having the tests check to make sure everything works.

When I chose an item from the list I made it bold, and when I had finished it I put a strike through it. If anything came up while working on that item, I added it to the list.

The only hiccup that I ran into while working on it was IDLE’s improper handling of the unittest’s exit. When the tests are finished, they throw some type of exception. Apparently this isn’t a problem with other runtimes, so the way I fixed it was surrounding the unittest.main() with a try: and except:. Nothing is hidden from the developer if a unit test fails.

My notes on “Test Driven Development: By Example” by Kent Beck

These are my unordered notes that I took while reading Test Driven Development: By Example, by Kent Beck. I took a different route with these notes as opposed to my previous notes on Effective C++. If you read both, let me know which way is more informative.

Test Driven Development: By Example is a book that teaches how you can test the software that you write proactively. Ron Jeffries said that the goal of TDD is “clean code that works.” When you write your code TDD, the tests tell you that it works, and since one of the steps of TDD is to refactor, you should have clean code that lacks duplication.

The book is set up in three distinct parts. The first part takes you through a simple currency exchange example and shows how you could write unit tests, starting with something that is achievable and building up from there. The second part explains how xUnit works, and interestingly, Kent shows how by having you write your own xUnit library in Python using TDD. Writing the testing library using tests? Yes, and it’s really cool how he does it. Part three covers many TDD design patterns and development processes. Here are the notes that I took while reading the book:

• While coding, you should make a to-do list. Tackle what is easy and if you notice anything else to do, just add it to the to-do list. You can come back to the list later for the next item to work on. This way, you won’t forget anything that comes to mind and can stay on track. Your to-do list can also be a list of tests that need to be made. These tests will then lead development of the feature.
• With TDD, you can test an experiment and back it out. You know right away if it will work or not.

• Three strategies for a green bar:
  • Fake It – Return a constant
  • Obvious Implementation – If the implementation is obvious, go ahead and implement it
  • Triangulation – Two tests that both cover the same code to get rid of faking it. If you are having trouble figuring out how to implement the code, triangulation can help you out.
• Obvious implementation is a fast way to implement what you know. Triangulation and Faking It are baby steps compared to Obvious Implementation.

• Value objects: once initialized, they don’t change. Anything that changes them returns a copy with the new value. Value objects must also implement operators like equals though.

• Impostor pattern: Objects that have the same external protocol but don’t behave the same way.

• Chapter 14 talks about creating a pair class. Isn’t there something like  std::pair in Java?

• Bill Wake says your tests should follow the three A’s: { Arrange, Act, Assert }
• In the same spirit of test first, you should write assertions first and then figure out what test code is needed.
• Don’t obscure the test results, use Evident Data to show what’s expected. This means that if a test is checking that a result is 2/3 the input, you shouldn’t precalculate the expected output. Instead, you should just show that the output is expected to be 2/3 * input.
• If a test needs to work on many values, start with just one, then refactor to many.

• You should end up with the same number of lines of test code as model code with TDD. This doubles the amount of code that you write, but it should limit the amount of regression that occurs, and give you an idea right away if your code works as intended.
• The number of changes per refactoring should have a fat tail, this is also called a Leptokurtotic profile.

Notable quotes:

• On xUnit, “Never in the annals of software engineering was so much owed by so many to so few lines of code” – Martin Fowler
• On TDD: “The goal is clean code that works” – Ron Jeffries