by Carl James | BLOOMINGTON, IN | Sept. 6, 2015
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?
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.
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.
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.
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:
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.