I was asked to review a new book by Packt Publishing called Test-Driven Python Development. I was really excited because it combined two of my three favorite programming topics that I can’t seem to stop reading about: Python and TDD/Unit Testing.
The book has many editing mistakes, but does a great, in-depth job of explaining TDD and good testing in Python. Continue Reading
Today’s article is something a little special. It’s the first article where I use code from my current personal project for examples. You will be getting “real world” examples and not silly, made-up examples like my Scientist and Pen example in my factories article.
Sorry, I was super busy and unable to write a blog post for this week. Instead, I’ll link you to a post I found recently that helps you to decide what to test next in order to incrementally create an algorithm. Check it out. Continue Reading
Sometimes, when you make a class, it directly instantiates an object to use in its methods. For example:
public void myFunc()
MyType object = new MyType();
this.thingy = object.getSomething();
This is generally viewed as bad, since you’re tightly coupling your class to the instantiated one. “But,” you say, “I know that I will never use any other class, and I certainly don’t want users of the class to be supplying alternatives to use.” These concerns are mostly valid, but they leave out a very important thing to pay attention to: testing. Continue Reading
There’s a fair amount of ideas out there about what you should name your unit test methods. Until recently, I had followed a variation of BDD‘s naming scheme, “shouldDoSomethingWhenGivenSomething”. BDD-esque naming is still what I consider the best naming scheme that I’ve seen out there (what I’m going to show you in this post doesn’t count for some interesting reasons that may or may not be clear to you when you’re done reading it). It’s certainly not bad, but I’ve got a few bones to pick with it, and, eventually, a solution.
Problem #1: Difficult Searching/Distinguishing
First off, BDD’s naming convention lends itself to long names that have repeated parts between different tests. For example, “shouldThrowMyExceptionWhenGivenInvalidParameter1” and “shouldThrowMyExceptionWhenGivenInvalidParameter2”. This can be a pain to deal with when a test suddenly goes red and you have to find it among all your other test methods by name in order to see what might be the problem. Continue Reading