Python Friday: Challenge #3

Unit / Functional Tests!

Don’t expect to write code without making mistakes. Test your code!

Let’s not go any further down the python challenge trail without introducing two of the most empowering techniques I have learned across any programming language. The Unit Test, and the Functional Test.

What is a Unit Test?

A unit test evaluates the result of a segment of application code.

How one of my tests typically runs [in bullet form]:

1. The test initializes
2. The test executes a segment of the application code
3. The test expects the result of the application code segment to be some value.
4. If the result is as expected, you get green letters in your terminal
5. If the result is not as expected, you get red letters in your terminal, with line info about the test that failed.

A Functional Test works similarly, but is meant to test how different pieces of application code, even imported modules, work together to create application functionality.

Testing Code Kills Bugs Early

I often write buggy code. If there is some gene that gives people the gift of flawless code writing, I do not have it.

I utilize Unit Tests and Functional Tests to catch my little garbage patches of code. So before I write 1,000 lines of code on top a Rube Goldberg-y module that ends up having more unexpected behaviors than features, It’s caught by the test.

This can be taken a step further. Instead of testing your code after writing it, you can write a test first, then write the application code to satisfy that test. This practice is called Test Driven Development.

Test Driven Development

Test Driven Development (TDD) is a technique used to ensure that nearly all code added to an application has it’s own unit test. It’s also used to drive the structure of the application. Writing the tests beforehand is like writing pseudo code on steroids. You get application structure templating, and regression testing using a single technique.

For more info, check out one of my favorite posts regarding TDD.

I Can Now Drive My Project with Tests

Before TDD I only tested a small portion of the code I wrote, and wrote pretty horrible tests. My tests were bad because testing code that already exists is harder than writing code to fit an expectation.

After TDD I test ~95% of the code I write, and my tests are far less horrible!

I won’t preach anymore about this because there are definitely mixed opinions on the practice. I can only speak from my own limited point of view here.

Scenario

You are creating a date function that should return a number that represents what day of the week it is. But before that… write a test that checks whether or not it is Friday.

And that’s all!

• Disclaimer — using a test to check for a day of the week is a bad idea. It’s like checking to see if it’s 9:30AM. It’s very unlikely that it’s 9:30AM, so writing a test to assert that it is, won’t be helpful. And that test would almost always fail! I did it to be kitschy because of the name of the blog!
• Also! In this example, because I am testing how a module would behave in an application, this is a functional test, and not a true unit test. Thank you u/b1ackcat!

Possible rage inducing opinion incoming:
I recommend using pytest to test code when first starting, and maybe always. Unittest has a ton of features, but also has a very rigid structure that can feel a little daunting, and potentially discourage the use of TDD.

The simplicity of pytest, as well as the friendly to read documentation make it the winner of my ‘Programmers Humble Opinion’ award.

pytest will need to be installed using pip3. It did not come standard with my copy of python 3.

In terminal:

pip3 install pytest

Then

py.test whatever_your_test_is_named.py

Let’s see the code:

Today's Solution is the simplest code of the Challenges so far. That’s because I wanted to stress the importance of tests for catching regressions and for improving code structure through the implementation of TDD.

There are really only two things that happen in the program

1. The function behavior is defined
2. Assert with a test that it is in fact Friday. If it is Friday, computer rewards you with pretty green letters in the terminal. If it is NOT Friday, computer expresses wrath with red letters in the terminal.

And yes, you don’t have to check for Friday, I’m just trying to stay on brand!

Personal Take-away

1. I really like pytest. I am sure I’ll end up liking unittest because it can mock, but for now I’m going to study it and determine whether or not I’ll need it for any of the code I’ll be writing.
2. The datetime module is pretty sweet, and It’s built right in. Yet another cool feature of the language that supports that mentality of ‘Let’s get some work done.’

In Closing

I will be providing my test code along with any sample code I give with future python challenges. I’m hoping somebody who really knows about tests will catch this and be like, “Listen here sonny, you’ve got your tests laid out all wrong.” and impart on me their unit testing wisdom.

Side note: No sources from Stack Overflow today. I don’t know if that is a success or not… AND prior to writing this article and getting feedback, I had no idea the difference between a functional test and a unit test!

Thanks for reading! If you liked this, give it a ❤!

Also, Thanks to the r/learnpython and r/python communities on Reddit for reading and helping me through this learning process!