8.3 Red - Video Tutorials & Practice Problems

<v Instructor>Now that we've written our initial tests,</v> it's time to get to an important testing state that we've discussed briefly before called red. This is where we have a failing test that we wanna get to pass. But first I'm gonna write a passing test for this pending test here. Our application code already handles mixed case palindromes. Let's review here just briefly. Remember, we've got two passing and two pending. So let's go in here. Function is zero arguments. And then it's pretty much the same as this Let's say mixedCase equals RaceCar with a capital C. And this should pass. Like that, three passing. By the way, I'd like to mention a nice technique, and this foreshadows our full red/green refactor testing cycle. How do we know that we really tested the right thing here? Well, one easy way to show that in fact, this test tests the right thing is to get rid of the thing that gets it to pass. So let's remove toLowerCase. This gives us a failing test. Aha. So now we restore it and it passes, which means we can be confident that we're actually testing the right thing. If we or some other developer comes along at some point and removes toLowerCase, the test suite will catch that right away by giving us a failing test. So you can see how useful a failing test can be. Well, what we wanna do right now is write a failing test for a palindrome with punctuation. This technique of writing the test first is sometimes known as test-driven development. We're letting the test drive our development forward. There are some people who take the extreme view that all software should always be written test first. I don't generally agree with this view, but there are a lot of situations where writing the test first makes a lot of sense. You can look at the text for some details on that, but suffice to say that in this situation, the test code is a lot simpler than the application code. When that's the case, in my experience, it's usually a good idea to write the test first. We can capture the behavior we want in a simple test, and then no matter how complicated the application code might be, if it gets the test to pass, we can be confident that it's probably right. So in this case, if we look here, it's pretty easy to write test code for a punctuated palindrome. Copy this stuff in here, paste it in, change this to punctuated, assert that it's a palindrome. Just give it a phrase that has some punctuation, such as, "Madam, I'm Adam." Because of the spaces, the comma, the apostrophe, and the period, our current palindrome method will not recognize this as a palindrome, and so the test should be red. But if we can get this test to green, then it must mean that our palindrome detector can detect more complicated palindromes like this. One of the good things about test-driven development is it gives you a way of thinking about how to structure your program, and often it will give you ideas for the application code. So in this case, let's think about how we might test something a little more detailed than just this palindrome. Well, we can already detect palindrome that have a mixed case like this, so all we need to do is take this string and select out everything in it that's a letter. That is to say, filter the letters and get rid of anything that isn't a letter. So to do that, we're going to write a letters method inside this Phrase object. We don't know exactly what it's going to look like, though, so let's write a test for it. Again, this is a case where writing a test is a lot easier than the application code. You can reuse this punctuated palindrome room here. And I'm gonna say it should return only letters and then function. So now we can assert that punctuatedPalindrome.letters is equal to just the letters in the string. We can do that with assert punctuatedPalindrome.letters triple equals, and then the letters, which are like this, MadamImAdam. Let's run the test suite. All right, so notice here we've got one failing test. That's from the previous palindrome test, palindrome with punctuation. And then we have a type error. So it's failing, but it's not failing in a very convenient way. So this is a good example of how a test can drive the application. This is telling us that we really need to define a letters method. So let's do that here. Now, notice I didn't say that we needed to get the letters method working. We're actually going to define what's called a stub. It's going to be a letters method, but it's not gonna be right. Not yet. We just wanna get past this type error. This.letters will be a function also called letters. Will be a function of zero arguments. And for now let's just return the content. This is definitely wrong, which is fine, 'cause we want this to be red. There we go. So we've got now for the palindrome with punctuation assertion error, meaning that we have a failing test, and then the same error here. Now, this would work, but if you look at the documentation for the assert module, which is linked in the text there are actually native assertions for a lot of things including what's called strict equality, this triple equals. And in those cases when there is a native assertion available, it's usually better to use it, because among other reasons, it gives us a more useful failing message it's assert.strictEqual, and then the first argument comma second argument. And it's always in the same order. It's always in actual comma expected. Indeed, this is true across different test frameworks, different languages. I don't know of any exceptions offhand. This is important for getting the right failing messages. So this is actual, that is to say, the thing we've calculated using our code, and then what we want it to be, the expected value, in this case, just the letters in the phrase. Save it and see what happened. You can see here assertion error false equals true. Take a look at the new error message. Ah, here we go. Now assertion error, it actually gives us the string should be triple equals to this other string. Expected is in green. That's here. Actual is in red, which is here. So you can see because we just returned the content, the content doesn't equal the letters, and so we have our failing test, as required. At this point, we're all set up. All we need to do is write the application code that gets these tests to green. At that point, we'll have a working palindrome detector, even for complicated things like the phrase, "Madam, I'm Adam."