What Test-Driven Development Is
00:17 So Martin, you were talking about test-driven development, so now you were creating tests after you created your function, and you were talking about TDD, which is short for test-driven development.
00:34 If I were to approach this in a test-driven development way, I wouldn’t start off by writing the function that actually does the work that we want to be done—in this case, doubling the characters—but I’d start off with a test file. I would probably make a plain function
00:50 without anything happening in there that just gives my intentions of what do I want it to do. And then I would start off by creating the tests first. So I would write this test and give my intentions that says, if I want to execute this function, I want it to double each character in the word that I’m passing to the function as an argument, right? This is what I’m defining in here, more or less.
I want that your function throws an error if you add in an empty string. So you expect some strings for
double_characters(), but if the string is empty, I want you to throw an error, and I want you to program it in an TDD way, a test-driven development way. Nice. All right, so, I’ll go ahead and create a new function in here.
02:46 And after that you pass in the arguments that you’d be passing to the function. So in this case, it would be an empty string. Okay? Yeah, so—This is essentially me calling the function like this. Yeah. Right.
and you would see that it ran two tests, and we have a failure in there. Okay. First of all, you can see that the first test passed. This is still a little dot. This is
test_double_characters_doubles_characters() that went well. But then I got a big
F here, which is that it failed, and now you can see the advantage of having this verbose naming,
test_double_characters_fails_on_empty_string(). So I know already what went wrong here,
So now when I go back over to the actual module where we’re writing
double_characters(), my next step is to implement these intentions that I wrote in the test and put it into this
Maybe that’s even— Is there an advantage to one or the other? I don’t really think there’s an advantage to either. I think people prefer to write Python like this because it implicitly checks that
word is a falsy value, an empty string.
if not word is going evaluate to
True if the word is empty. That’s a double negation, right? I don’t know, it might actually be easier to read if we do this. So for readability, maybe that’s easier. Okay. So let’s leave it like that.
So now you’re starting an IPython session, and you’re running
double_characters() with an empty string. Correct. And it worked, and now you can see that we get the
ValueError and even with the message that I passed in here before. Cool. Okay, so that means test-driven development means that you are first writing a test.
06:40 You are expecting the test to fail because you haven’t created the code yet to match the test. So then you’re running your test, the test fails, and then you create the code to make this test pass.
06:55 Exactly. And you basically repeat this until you are at this point where you want to end up. Yep. And this kind of differentiates to the approach you had at the beginning of our session today, where you created the code and then afterward created a test to match the code and to check if it works like you wanted to, and maybe you would spot some issues with it, and then you kind of like stumble into test-driven development, but this was kind of like the other way around.
07:50 I don’t think I have, like, a strong preference either way. I think sometimes it’s fun to start with the code, and sometimes it can be helpful to start with the test, just like it happened in this session.
08:00 I might want to get the functionality, the first functionality down, and then maybe I can think of edge cases of when might it fail. Like I didn’t even necessarily know that it would not fail if it’s a more complex function.
08:13 And I don’t exactly know what happens when I try to double a string. Right. Then I wouldn’t necessarily know that it fails, but here I’m just saying I want it to fail, and then I can go back and implement that. Yeah.
09:28 In the next part, Martin and I will recap the session. We’ll share our impressions about how things went and how the session maybe compared to a coding interview and what I particularly liked about the way that he was approaching this coding challenge.
Become a Member to join the conversation.