Test Driven Development

As I continue to discuss my foray into the world of programming computers, my goal

is still to make this blog accessible to those who believe themselves to be

non-technical. I do not wish to turn you away, but rather to give you some insights into

the world of programming from someone who remembers not being a developer.

So why would I, this early, discuss a below-the-surface, seemingly technical, topic like testing code?

1. The learning methods I used to understand why testing is vital are

applicable to almost anything 2. Concepts about programming should be more transparent 3. If you are reading this, you are using software. Don't you, as a consumer,

want to understand how programmers know that the program is working the way it should?

I have had family members ask me, "why didn't you pursue computer programming years

ago?" I have always liked and used technology. Even I, a self-proclaimed tech nerd,

was intimidated by the programming culture. I would be lying if I were to say

I am still not somewhat intimidated by it even today. I have made the choice to face my fears and

succeed regardless of my fear of the general culture.

Programmers often seem to have a "my way or the highway" kind of attitude about the

process of writing code. This is very ironic given the vast differences ecosystems and

ability to innovate that are out in the programming world. Ironic or not, it is out there.

Possibly it can be attributed by how valuable their employers see their skills and that

having those attitudes have little in the way of obvious negative consequences. A

good programmer is not going to usually lose his job (yes - I said "his" as the vast majority

of programmers are men, and that is another problem).

Part of what I do to overcome my intimidation is by listening to podcasts about programming. I am

very much an auditory learner. While much of these discussions are over my head at this stage,

not all are, and I feel I can get more familiar with how those in the industry communicate

by listening to them talk to each other.

Some of my favorite podcasts:

• Podcast.__init__
• Talk Python to Me
• Programming Throwdown
• Django Round-Up(no longer recording but good past content)
• Python Testing

(brand new and all about testing)

I list the Django Round-Up in particular

because one of the podcast's hosts is a obsessed about testing code and the group jokes that

his only criteria on judging if software is worthy is whether or not it is had good tests written.

All of the podcasts listen discuss testing to one degree or another and obvilously

Python Testing is all about testing.

I was first exposed to testing by the Pluralsight course

Python - Beyond the Basics.

In this course instructor Robert Smallshire has a module on iterators. What is so different about this module is

that he uses a process called Test-driven Development to write the code examples.

What is a test?

In these cases a test is a bit of code that gives sample inputs to a function and

then compares its results to the results the programmer expected to get. If the results

match then the test "passes." If the results do not match, or the program reports an error

the test "fails." Watch Smallshire go through this and typing along with him I got the

feeling that I hear from many of the podcasts that I listen to that some people feel that

testing is a boring task. Keep in mind, I was simply copying his examples and trying to keep up

in both the actual program and a separate testing module (just a fancy word for file).

It left a bit of a bad taste in my mouth about testing and I went on to other things

like learning web frameworks and practicing writing code based on

Simple Programming Problems.

What I did not do was write automated tests for these.

After listening to more and more pronouncements of how important testing is, especially

with the Python Testing Podcast, I

decided to give it another try. I sought out the course

Unit Testing with Python on Pluralsight and

learned what I could.

I have since gotten deep into the process of writing a Python program that has multiple classes

and dozens of methods. I am writing tests in pytest

and in the process I came to an epiphany: using the

Test-driven Development method is easier for me than not to. I have already written 91 passing

tests for my code, but what I have found is having all of the tests gives me the confidence to move on

and forces me to write the best code I can. Before I would worry about breaking a functionality

I had already written and by running all of the tests I wrote (called regression testing) I

was assured that, if they passed, I was good to move on. It also forced me to write my code in

smaller, easier to manage, and easier to test sections. SO even though I am writing more code, I am

moving through my project at a faster pace and have more confidence in the product that I am producing

than I would if I had not.

What is the Lesson?

For me the lesson is that having multiple sources of learning and exposure to the new world

convinced me to try something that was outside of my comfort zone and it has led to success.

By choosing to learn from different sources:

• online learning sites like Pluralsight
• a course at Indiana University Bloomington where I work
• listening to podcasts on programming

I was able to hear a similar message from different experts and realize that they did know

what they were talking about and if I put an effort forth it would worth it.