Test Driven Development, TDD, can be intimidating to try. In this episode, Chris May shares his experience with adding testing and TDD to his work flow. His story will help lots of people overcome testing anxiety.
Transcript for episode 76 of the Test & Code Podcast
This transcript starts as an auto generated transcript.
PRs welcome if you want to help fix any errors.
This is Test and Code Code, episode 76, Test Driven Development, or TDD, can be intimidating to try. Why is that and how can we make it less scary? Well, that’s what this episode is about. Chris May is a Python developer developer and the cofounder of Pi RVA, the Richmond, Virginia Python group. In this episode, Chris shares his experience with adding test and code to his workflow. I really enjoyed talking with Chris and I think his story will help lots of people overcome testing anxiety. Thank you, Chris. And also thank you to Pie Charm for sponsoring this episode.
Welcome to Test and Code, a podcast about software development, software testing, and Python.
Welcome to Test and Code. Today on the show, I’m excited to have Chris May. We’ve never talked before other than, like, starting a few minutes ago. So, Chris, can you tell everybody who you are?
Sure. Yeah.
Let’s see.
I’m in a weird place because I have the best way to describe what I do is, like a problem solver because I’ve started off in graphic design and went on to full stack development and started learning Python about ten years ago. And so now I kind of do some full stack development at my current job and use Python to create tools, do some research and analytics. And I’m also trying to help a couple of departments to transition over to Python, too. So I’ve got a lot of hats I wear these days.
Nice.
Yeah.
Do you play an individual contributor role or are you a manager?
I’m a contributor, yeah.
Okay.
In fact, my title is Full Stack Engineer, but it’s amazing how much I can overflow.
Well, the full and full stack.
It’s cool.
One heck of a stack.
Yeah.
But things you started from graphic design?
I did.
That’s kind of neat.
So how did you transition from graphic design into full stack stuff?
Essentially, it started. So let me take a little step. Back in College, I actually started off as a computer scientist.
I remember my freshman year, there’s a bunch of us CS majors on my hall, and we all started building websites, and people came to me and were like, Chris, your website looks better than all of ours.
And I was like, oh, thanks.
At the time, I also had a copy of Photoshop that I bought at a crazy whatever place and essentially started messing around Photoshop and doing all sorts of different things and people. One guy from the hall kept coming into my room and was like, Chris, I think you’re in the wrong major.
What are you talking about? He’s like, It looks like you might enjoy graph design a little bit more.
What is this? I’ve never heard of this. And he’s like, oh, it’s in the art program. I’m like, Well, I’m no artist.
I’m a computer person, you see, because I’ve grown up, like, making learned basic. When I was in, like, first grade, I was born with a keyboard in my hand practically.
But what he said kind of stuck in my head. And long story short, I ended up going down to the art Department and talked to the head of the graphic design Department, who invited me to one of the senior level classes to see if there was anything I was interested in. And I walked in and I’m like, Holy crap, these people are doing what I do in my free time and they’re getting a degree.
And then I walked behind them and I’m like, Holy crap, I can actually give them pointers on making this better.
Okay? I am in the wrong nature and just loved it. Actually, my QCA Skyrocketed, I was having a really hard time in the computer science Department. The way that they were teaching me just didn’t sync up with how I learned. Okay, so essentially graduated with a graphic design degree, which this is much longer talk than intended to go. But essentially at one of my jobs, I started off with Graph Designer, but I kept telling you, I have this history of web development, especially front end web development. At the time it was web develop. Nobody knew, like front end. I mean, you knew front end and back then, but there wasn’t necessarily a full stack development. And there was a big Truncating company that I worked for and they needed a redesign for their website and asked the company to design it, but they didn’t have anybody to implement it. And so I was like, yeah, I’ll do this and took their design, created the website for the company. And while doing that, I actually learned JavaScript, which I had been avoiding for a long time because I thought the whole Java, there was a time where there was Java in the browser and it was like horrible.
So I avoided it just because it had Java in the name and then learned that JavaScript is much less intimidating in Java and fell in love with it initially.
And I just started enjoying making the websites. At some point I was like, I want to get more into the server side. And at the time, Ruby on Rails is like the big thing. And so I started learning that. And a good friend of mine was like, Before I get too deep into Ruby, maybe you should look at this Python thing. I think you’ll enjoy it a lot more. And boy am I glad he did because since then I started learning some web development frameworks in Python and then start building tools and just fell in love with the language. More so than JavaScript by far, and in fact, so much so. I’m just amazed at what you can do with Python that I started a local user group here in Richmond and just try to help other people find Python and enrich their lives. So it’s just been a long, fun journey for me.
I love hearing stories like that, and I love hearing people doing what they really should be doing. So you really got into graphic design through computers?
Well, one of the things we wanted to talk about today is your experience with software testing and with test driven development, and you’ve got a lot of ideas about this, man.
And thanks to you, your book has really fuelled my passion for this, which is because it’s one of those things where I’ve been around a lot.
In my last few roles I’ve been a part of there’s been a lot of testing around me, but my role has never really been one that’s tested the software we’ve written, mostly because I’m a front end of websites for a long time, but heard a lot of things and then read your book and was like, okay, well, let’s get Pi test in here and figure out how to use it. Nice reading your book. Answered a ton of questions. And then it’s been really cool to like, actually, I feel like you can listen to podcasts, you can read books. But really the thing that really unlocks it for me is, like, sitting down and actually forcing myself to do it.
In doing that, I’m just like.
Okay, this is great stuff everybody’s tried is a lot of the testing you’re doing using something like Selenium or something to test through the actual front door, or are you going through an API?
So far, I’ve not used Selenium at least within the last five or seven years.
Most of what I’m doing is actually as my teammates and I are building the code that actually creates the website, we’re running tests to say the way I think about it is I have this problem I want to solve. Like, we want to create a report, and so let’s create a test that says, all right, what are we going to create that’s going to run this report? And so we’ll create that, and then we’ll run a test to make sure it’s there. Actually usually I’ll search false first to make sure, like, okay, I have a test, it’s running, it’s failing, but at least there’s something there that it’s talking to. And over time, we just keep writing tests to say, like, okay, what do we need to give this function to write a report? And then we’ll give it a thing. And it’s kind of like an Iterative process to build up over time a suite of tests that test the code that generates the report and help us to figure out what do we need right now kind of a thing.
Oh, nice. So you’re using it in a very test driven development mindset, even of building up the API of whatever you’re testing while you’re testing it.
Yeah, that’s one thing that I was like, I’m still even trying to get better at because I feel like that’s how I’ve learned that. Like, okay, my code is an API. Like, you’re saying in my head, especially come from the front end development. I think an API is JSON or Ajax called or some remote thing. But the more I’m like doing test driven, it’s like, okay, my code is an API. What am I using to call this report function?
I love that you’re excited about it.
I was going to say it’s really funny because for me, we had a very short time frame to create essentially a website that would allow one of our partners to send us data and we would generate reports and stuff like that. And I was like, I think we had like, just under a month to get this thing live.
We were essentially called in last minute to be like, all right, firefighters. And I was like, okay, we have got to do test driven development or else we won’t know. We have to run so fast. We have to create this so fast that without tests to prove to us that what we’re building is what we expect and actually delivering what we want, we’re just going to be constantly like, where the heck are we? What do we need to do? Can we even trust what we’ve done?
And that was hugely critical for us.
Nice, good success story.
Yeah, nice to have one every now and then.
So do you have any people around you that are reluctant to jump on the writing test bandwagon?
Yeah.
Some of the other members of my team in particular, one of the guys was actually telling me today, he understands, I guess, conceptually, but hasn’t bought in yet. And he kind of wants to sit down with me and kind of help him understand why we want to do it and how to do it.
He was saying talking to me was exciting to him because he’s like, okay, I can tell you’re excited about it, and I can tell this is a good thing. But when I talked to him, I have all this stuff that I’ve been thinking about for ten years, and I’m trying to explain to him, but of course, I don’t know what he knows, what he doesn’t know. And I miss out skip over all the stuff that he needs to know. He just kind of watches me do things. I try to explain it. There’s all this stuff he doesn’t know. So what I’m hoping is, over the next few weeks I’m going to talk to him. But I also have been writing an article and a book, actually about that includes test driven development. And I have an article on my blog that kind of goes into some of this about some of the steps that I took to get myself into a test driven development and some of the success stories and the failures that we had on my team.
Oh, wonderful. Yeah, I know exactly what you mean by you’re trying to talk to somebody, but I’m that way a lot. I’m trying to tell somebody about testing, but I assume, obviously incorrectly, that they’ve read all of the same articles I have for the last ten years.
And on top of that, you have all the people who are like, we need 100% coverage. We need to write a test about every single thing you write. And it’s like that’s a big mountain to climb and intimidating. I mean, that’s actually part of the reason why I don’t remember how many years ago I decided every kind of personal project I’m going to write, I’m going to do test driven development. And it failed because I was just so intimidated with, well, how do I do it? And I don’t know exactly what I’m writing yet. So how do I write the test for it? And it was just so much fear that was instilled in me just because I’ve heard of all these rules. And once I kind of learned, you know, let’s just try this and let the rules kind of go off to the side and explore on your own. Then I started getting some traction.
Well, and I like how you described what you’re using it for, it’s to maintain confidence in your system.
So you’re writing tests to make sure that you’re doing what you think you’re doing and to make sure that you’re confident that you’re not going to break it and then you can run faster.
Yeah. So that’s actually one of the things that I’m frustrated with. A lot of the teaching of test driven development is they do these toy examples that are really small, and then you think as you extrapolating, well, that’s like just this whole book described, like what, five minutes of my work day?
So if I blow up five minutes of my work day into, like 4 hours of this iterative process, I’m not going to get anything done totally. But I think the intent was we’re just showing a toy example. You can run as fast as you can until you start tripping. And when you start tripping, slow down and do smaller level tests.
Thank you, PyCharm, for sponsoring this episode. Pycharm has a special offer for test and code listeners now through June 10, you can try PyCharm Pro for free for four months by going to testinggo PyCharm. What’s that you say? You’re already using the Community edition, so why should you bother with the Pro version? Well, I’m glad you asked. Python Pro includes extra support for development with SQL Alchemy and Python with Django Flask and Pyramid Web Frameworks with Ginger Two and Maco templates, and even gives you professional class tools for code profiling and code coverage. Beautifully integrated, I might add, and even duplicate code detection and so much more. Now, maybe today you don’t need this much power, but maybe tomorrow or next week you will. So please don’t wait. Grab a copy of Pro and at least play with the integrated code coverage today by going to Testingcode.com Piechar.
You talked about your article?
Yes.
Okay. So the article is called Don’t Be Afraid of Test Driven Development, and I really like it.
Well, thank you.
There’s a lot of stuff I want to cover here. At the beginning of your introduction to it is it took much longer than I should have to get started with testing my code.
You were intimidated by the rules you felt you had to follow, rules that you had to get past in order to let yourself explore, try, fail, and then succeed.
Yeah, sure.
Can you tell me more about that? What stopped you?
Yeah, I don’t know if this is like a personality trait for me or what, but I feel like especially with all the discussion around test driven development, I just felt like there’s like a specific way you’re supposed to do it. It just seemed like so many people in explaining it or something. It just seemed like there was something I was missing or something. Like there was a prescribed method you should do it. But nobody ever actually, I guess, writes out what that prescription is. And so every time I would start, I was like, am I doing this the right way? I don’t think so. I bet I’m messing this up. And as a result, I would especially try at night on my own since most of the teams I worked with, like, if I was a part of the team that did do testing at the time, I was in front end development and they didn’t really care if we did any testing for the front end, which is kind of funny, but yeah, so I’d be at home all by myself trying to build something. And especially at that time too.
I was probably in Python, maybe only a couple of years, and that definitely wasn’t full time development. That was just kind of me exploring on my own. So I just kind of felt like I was already intimidated with trying to figure out virtual environments and then like, oh, I’m trying a new framework.
I don’t even know. I guess it was Django at the time, but that was trying out or maybe Web to Pi. And I was just like, there’s just so many levels of things that I had to try to figure out that test driven development. On top of that, I just felt like destined to failure, or at least that I wasn’t doing it right. One thing that really started clicking for me was like, I think I mentioned in the article about how for me the big thing was to actually let a test fail.
It’s kind of funny, like, looking back on it, but I wanted so hard to not let tests fail, to type it out and have it work perfectly the first time.
Oh, yeah, right.
And then especially if I were to have a test running and working, and then it failed because I was working on it, I was just like, oh crap, I did something wrong. I got to fix it now. And when I started getting into the habit of actually letting a test fail first, especially, I think I mentioned an article sometimes I have no idea what I really want to write. Like, I kind of a vague sense of what the code needs to do and I’ll start writing out the test case and I’ll think, wait, I know. Like for instance, I know I need to write a report, but that’s the output. Like, what do I actually need to write?
What do I want to exist in order to get a report from it? And what do I want to pass into it? And what happens if it doesn’t work? Right? And these are all questions that don’t really start coming up until I write like an Assert false. And then once the test runs and it fails, my brain kind of has a moment to say like, oh, wait, okay, that’s already done. That’s not a big deal. Things have failed and everything’s okay. And now I can actually stop and think, wait, what would be nice if it was there?
Yeah. I think one of the things that in test driven development tutorials, they often say to write a test that fails first, partly just to make sure that your test is getting run. Well, we’re not really that concerned about that because we’re pretty sure unless we misspelled test underscore, it’s going to probably get run. But there is some reality to that. There’s been times where I’ve messed up, especially on other frameworks where you have to derive from a particular class and if you get the spelling wrong or something, it won’t get run.
Or if like, I don’t know, I use my skip statement wrong or something and it’s getting skipped. And I think it’s not. So there’s some reality, but I’ve never heard before. It’s one of the reasons why I really love your article.
The notion that just to get past the blank page block, just writing a test down and just go ahead and write Assert false. If you don’t know what else to write, write that and then run it. And then you’ve got all of the framework out of the way, you’ve got the framework working.
And then also you go onto an example, your example of the report in the article, you’re just calling the library with the report function with no parameters and it isn’t there yet. You know it’s going to fail, but it’s a place to start.
Yeah.
Anyway, that’s a really neat way.
As an example, you’re not trying to go through and teach people all the nitty gritty little details, but just how to get over the blank page.
Yeah, good point. Yeah, absolutely.
One of the other things I like, the blank page was cool. And then also there’s a great quote. I’m going to go ahead and read it because I almost highlighted the entire article it’s great quotes, but iterate a lot. So you say iterate iterate iterate. Whenever you develop code or write tests, chances are the first thing you’re going to write is going to get edited or completely replaced. So try to not let yourself be intimidated by the stress of doing it correctly or not knowing what to test. I like that. Write down what you know now, update it later. So this is a mindset of like a first draft thing, knowing that both your test and code code are going to get rewritten anyway, probably or heavily modified beyond recognition. So just go ahead and get it down.
This is great. I love this tutorial.
And you saying that reminds me of another thing that really got to me was like I had a rule in my head that I had to write a test for every function that I wrote.
And once I kind of let go of that and let myself write one test that could cover multiple functions or classes or whatever.
For me, it was like, especially I think that report one was a good one because I have some tests that do test to make sure things can get pulled from the database or whatever. But for this report, what was important is this report got made, and whether it hit all these other things or not, it didn’t matter in this case.
And that in fact, like you’re saying, I gave myself permission to write the test knowing that it was going to be improved later. And in fact, it’s amazing how many tests were completely rewritten. And I think that one thing that was great about that compared to what I was thinking before was that was intimidating for me to think that I had to write a test for every function knowing that functions change. And that meant I would have to change both the function and the test, which sometimes that’s a great thing, but you don’t have to do that every single time. That just gave me such a sense of like it reduced the weight on my shoulders, I guess I should say, because now I have one test that tests like a business case, I guess you could say that this report gets generated and we could change how it happens and still the test will pass as long as the report gets generated the way we expect it to.
Right. If this report function goes off and calls a bunch of helper functions, if those helper functions don’t work, the final test is not going to work, right?
Yeah.
And then there are some cases, of course, where like some helper function, you’ve isolated some piece of logic into one function that is complicated enough that you’re kind of not sure that you can get it right. So that would be a good place to go ahead and direct some attention and some test cases through it on itself. But like you said, some of the helper stuff that you’re just, I don’t know, translating units or something silly like that.
It’s visually so simple. It’s probably fine. Plus it’s covered by the parent test anyway.
Exactly.
Anyway, do you have any rules that you think of when you’re writing tests now?
Well, I feel like the first rule is always to start with the test, and that one is one that I don’t always pass myself or rule that there are times where I get into work here and I’m like, okay, well, I need to do this thing and I’ll jump in and start doing it. After like an hour or so, I’m like, I haven’t written any tests. What am I doing?
But you’re doing that not to satisfy some outside group or something. You are doing it because you know that you’re going to appreciate it later.
Exactly. Yeah, absolutely.
Especially like there have been a few times where working with other people, sometimes you realize, like the code I have found it that’s one thing I’ve really enjoyed discovering with these tests is to look at the test to see how we expect our code to be used.
And especially like when a coworker will write a portion of the application, I could look to see his tests and say, oh, this is how I should be using it. If I’m using it this way, I could also use it this way.
Yeah. It’s just one other aspect I enjoy. I’ve discovered I guess.
You’Re working with other people that are also writing tests then.
Yeah, at this time.
Right now, the project I’m working on is very small, but I have a couple of other colleagues that we’ve collaborated on a few projects, and I hope to again.
Okay.
Now one of the things that some people like to do is to maintain a certain level of code coverage.
Are you using code coverage metrics for your tests?
We haven’t yet. That’s something I definitely want to look into.
That was actually kind of thing. That was another rule that I was intimidated by was to try to get to that 100% coverage and keep it there and kind of giving me permission to relax about that has helped. But I definitely still run, especially with Pie Charm. I run coverage tests pretty frequently and see what’s getting missed, especially I love how in the gutters you can see what gets skipped and whatnot and to be like, oh, I definitely need to write a test case for this. That’s super helpful.
Oh, yeah. And especially forgetting the percentages.
If you were writing a test, if you got the test in one panel or something and your code in another panel and you think you’re writing tests for it. But the coverage report says it’s not covered. That’s a great use for that.
But I thought I was testing this case right here. It’s not hitting it, clearly.
Absolutely.
And that’s not even a percentage thing. You don’t need percents for that. It’s just this code isn’t getting covered.
Yeah, that is cool. Yeah. I didn’t even think about that as a good use model for that now. So do you have any before we get off on to other topics, do you have any other testing or test driven development tidbits you’d like to pass on?
You know, my thought is essentially to keep it simple and just let yourself discover it yourself.
I felt like I needed somebody to give me permission to do that, and I want to give that permission to any listener who wants to explore it, to just try it out, give it a chance to breathe, try it out on whether it’s a personal project or something at work.
Don’t feel like you have to get it right the first time.
Try a couple of mornings or so to see how it goes and see what develops that.
I’m sure that after a couple of weeks of doing this here and there experimenting, you might find you’ll get some benefit from it.
Yeah, I think that’s great. Give yourself permission to try it and not hold yourself against any sort of standard. And it can be a solo effort. Even if you’re in a team with a lot of people that aren’t doing it, you can do it for your own code. You can do it for the functionality that you’re responsible for.
Yeah, that’s a great point.
You’re doing a user group in Richmond.
Yeah.
That’s so cool. How long have you been doing that?
I forget it’s been three or four. I guess it’s been three, four or five years now. I don’t remember when we started it.
Yeah. And how often do you meet?
We meet every month. Almost every month.
I’m in the Portland area. Portland, Oregon. I’ve been kicking around the idea of trying to start up a west side meetup for a couple of years now. It’s a little intimidating to think about.
Is it a lot of work to get one started?
It is a lot, especially for one person.
And that was key for me, too.
I had been thinking about it for a year ish or so. And the day I was going to bring it up, I was working for a company and we had a Slack channel.
And the day I was literally typing in the sentence like, hey, I think we need a Python user group here. And as I was typing it, one of my coworkers put that essentially the same message in Slack. And I was like, okay, he and I are going to do it.
We talked about it for probably a couple of weeks and decided, all right, this is going to be our launch date. And we got a meet up page. And we’re like, let’s just see who shows up if it’s something that other people enjoy. And honestly, I don’t remember how many people showed up. I think we had 30 people.
We just asked this restaurant if we could hang out there. And next thing, so many people came and we took over the restaurant. I mean, people came down from at least an hour away in Fredericksburg to come down for this inaugural one. And we’re like, okay, well, this is something we need to do.
And honestly, it’s been in some ways, it kind of builds its own momentum, which is really nice, especially if you have organizers you can work with.
Like, for me, I had to kind of step away for a little while because I had some health issues. And, man, I tell you, we had that time. We had three organizers total, and that was just such a huge relief to know the other guys had it taken care of.
And then as I come back to full health, I’ve been able to pick things back up and work.
So that’s key. I’d say if you want to start something like this, pick at least one other person who seems into this. I find three is a really good number because there’s not a lot of work that has to happen, but it’s just work that you each need to keep each other accountable to do something each month, so to speak.
Okay. And if one person needs to step away for a little while, there’s still two left to take over. That’s a good idea.
Because life happens, work gets busy, anything.
Things just pop up all the time.
There’s a lot of Grace that you need to be an organizer.
Nice. Okay. Well, actually, that’s kind of inspiring. I like the idea.
It’s been really, honestly very rewarding. I mean, it’s been really surprising because I’m just like an average dude. Right.
And it’s just so weird to have people. I was in a conversation with somebody the other day, and they were saying that they were doing something with me, and they’re like, you know, Chris Nay, like, he’s a Python guy.
When I heard that, I was shocked because there’s nothing special about me. It seems I’m just a guy.
And yet being the co founderorganizer of a user group has a certain cachet that you wouldn’t expect. And I don’t wield it. I don’t know how to wield it, but I just try to do it to serve the people around me well.
The people that step up and do just a little bit, 10% extra to help out everybody else around them, it is a big deal because there’s not very many people doing it.
That’s a good point.
How many people show up usually, or does it vary?
It varies a good bit. Usually we’re getting around like 20 to 30 on an average night. It can go. I think our biggest one has been almost 90, like 80 to 90 for some of the data science talks.
They tend to come out would work for those.
Okay, so cool.
Tell me what’s going on with the book.
Yeah, thanks for asking.
I’m writing this book.
It’s kind of a passion project because especially over the last two or three years, I’ve been learning Python for over ten years or about ten years. And especially the last two or three years, I’ve really hit upon a bunch of what I consider, like, best practices. I don’t know if it’s necessarily everybody would consider them best practices, but a lot of things that made my life easier when I’m creating new projects or especially like deploying websites to servers or sharing code with people. And the more I shared with people, especially here at work about these things, it was really helping them. And I’m like, okay, I need to collect these and put it out there. So I decided to write this book and I just want to kind of help people.
We’ll put a link in the show notes for how people can find out more about this.
Yeah, I’ve got a page that kind of where you can sign up to get updates. I’ll be sending out updates on what I’m writing and love to hear feedback on what people want to hear. I’ll also send out some free content as I’m developing it to those people.
I haven’t figured out what I’m going to share yet, but I wanted to just put things out there. I figured there are some people who are just not going to buy this book, but they should benefit from some of the content. And so I want to put that out there for free. Then I want to have this core book that’s going to have all the best practices. And I want to put out some kind of premium content that will be kind of like some videos of walking through, setting up a project or converting a project to use like set up Pi and some test driven stuff, maybe some stuff, particularly to Django that I’ve learned recently, too. So if you’re not interested in that, you don’t have to purchase that. But you have this core book that will help you through your years of Python development.
Okay. I think it’s awesome you’re doing it. And I will be reading along with everybody else and there’ll be fun. Well, thank you so much for coming on the show. And if people want to get a hold of you again, you’re on Twitter and what’s your blog?
My blog is at storiesinmypocket.com. Yeah. And my Twitter handle Ismay if you want to follow me there.
Well, awesome. We will talk to you later.
Sounds great. Thanks so much. And thanks for your support. I really appreciate all you’ve done to promote and to retweet my tweets.
Yeah, you bet.
Thank you, Chris, for coming on the show. And thanks to Pie PyCharm for sponsoring this episode. Again, this is a short extension to the four month Pro trial. It ends June 10. Go to testandcode.com/pycharm to get the Protrial license and at the very least try out the cool coverage, integration or one of the other pro. Goodies. Thank you, Patreon supporters for your continued support. And thank you the listener for listening to the show and spreading the word. That’s all for now. Now go out and test something and maybe even try some TDD.