In the last lesson, we managed to add in a simple unit test in order to be able to ensure that our code will work correctly, given the input of 12345. However, in the lesson before that, we actually took a look at a situation, or a words.txt file, that our application didn't work well on. This was the empty file, which if I go ahead and set the words.txt to be empty again, and run the code using the gorun command, you can see it produces the number 1, when instead we're expecting the number 0.

So in this lesson, we're going to go ahead and fix that, and we're going to make use of test-driven development to do so, now that we have our tests up and running. Before I do, I'm just going to go ahead and revert the words.txt back to its original state. In order to do so, let's go ahead and actually define yet another test case inside of our test count words function. In this case, we want to go ahead and set our test input to be an empty string.

This empty string is known as an edge case. Edge cases are problems or situations that occur at the extreme operating parameters. Extreme being either the maximum or minimum. In this case, the extreme is an empty input, i.e. it's the minimum operating parameter. What happens if our application tries to count the number of words in an empty file? In this case, the expectation is 0. However, as we know, our application currently counts this as 1.

By the way, I'm just going to go ahead and change the count words function to be uppercase. There is a good reason to change this name to uppercase, which sets it to be an exported function. We'll talk more about that later on, however. For the meantime, I'm doing it just to make things a little easier later on throughout the course. It won't make much of a change to our application at the moment, however.

Okay, with that, we're now calling count words with our input of empty string. Additionally, we don't have to define this here if we want to. We could just define it in line, but I'm going to go ahead and keep this because you'll see why in the next lesson. Let's go ahead and add in a simple assertion. So if result is not equal to once, we'll just do t.fail yet again.

Now, when I go ahead and run these tests using the go test command, we should expect this test to fail, which it does. However, you'll notice that this failure output isn't actually very useful. We don't receive any information about why the test has failed. Beforehand, when we had a single test, this was easy to understand why, as we knew that this was the only point of failure within our test code. However, now we have two points of failures.

One failure on line 12, which is if the once is not 5 given the input string of 1, 2, 3, 4, 5, and one failure on line 21, which can occur given an empty input string that doesn't match the expectation of 0. Currently, it would be nice to know which failure is actually causing our test to fail, which our output currently doesn't give us any indication of.

Fortunately, the t type of the testing package does provide the ability for us to actually communicate what went wrong, which is by using either the log method or the logf method of the testing.t type. These methods allow you to print to the testing output, which can be used to communicate what actually went wrong, but it also gives some additional features. As you can see, there are two types of methods we can use. For the moment, let's just use the log method, although we'll take a look at the logf shortly.

As you can see in the documentation, this method is analogous to print line, so it's very similar to what we've seen before. In this case, let's go ahead and add in the following string: Expected, and we wanted the once, got, and we got our result. And we'll go ahead and copy this line and also paste it down on line 22 as well.

Now, if we go ahead and run our tests again, this time, you can see we get some more information about why the test failed. As you can see, we expected zero, and we got one. In addition to the log line that we're printing out, we also have an indication of where it failed in the actual test file. As you can see, main_test.go, line 22, which is right here.

If I go ahead and quickly make this first test to fail, and run this code again, you can see we get two outputs, one on line 12 and one on line 22, both letting us know what the expectation was and what we received, as well as where in the test file it's failing. This is very useful for being able to debug, so that we can easily see why our test is failing, and know exactly where the test assertion is.

So we're going to go ahead and make use of it. However, before we do, as I mentioned, there are two different methods we could use, either t.log or t.logf. Logf, and well, pretty much all methods that involve writing to the console that end in f, such as fmt.printf, s.printf, etc. These methods take what's known as a format string as their first argument, which is the string that you can use for actually printing, but it accepts the concepts of verbs, which allow you to perform what's known as string interpolation.

For example, we could go ahead and replace our log string with the following: Expected and got. Then in order to interpolate values into this string, we use a verb, which is denoted by the percent sign, followed by a single letter character, depending on what the type of the value is. In our case, because we're printing out an integer, we use the value of d. If we wanted to do a string, we would use s. If we wanted to do a float, we would use f. Go also provides a verb that works with pretty much any value, which is the %v, which stands for value. So if you're not too sure about which one to use, you can just go ahead and use this.

Now, in order to actually pass in the values to interpolate into this string, we can just do as follows, passing them in as parameters afterwards, and they will be interpolated as to their relevant index position. So the once is the first one, and it will be assigned to the first verb. Now, if we go ahead and run this using the go test command, you can see we get the same output as we had before, where our values are being interpolated into the string.

I'm going to go ahead and change the instances of the v verb to be a verb of integer, just because personally, I grew up with C and C++, and this is how string interpolation was done in those languages. And I think it's always better to constrain types when available, even though in this case, using the v verb is probably a better approach, just because it's string interpolation. You don't need it to be type-safe most of the time.

In any case, with that, we're now able to have better log output when it comes to our test cases. Now we can go about solving the situation we have at hand, which is where we're expecting zero words for an empty string, but we're getting back one. If we head back on over to our count words function, let's take a look at why this is happening.

As you can see, on line 17, we're assigning the word count of zero by default, which is the correct thing to do. Then we're iterating over and detecting the number of spaces inside of our data slice. Then whenever we detect a space, we're incrementing the word count by one. However, the issue is on line 25, where we increment the word count by one in order to make up for the delta between number of words and number of spaces. However, in this case, we don't have any words, so we're incrementing the word count by one regardless. This is the root cause of our issue, as it means we never really return the value of zero or we never have zero words, and we'll always have a baseline value of one.

So how can we go about solving this? Well, the easiest way to do so is to just check to see whether or not we have an empty slice of bytes. And if so, we then won't increment the word count. To do this, we can just go ahead and check the length of our slice of bytes. So if length of data is not equal to zero, that we can do is greater than zero, then we'll increment our word count as follows. Now if we go and test our code, let's go ahead and clear this old test and run the test again, you can see our test is now passing.

With that, we've managed to solve the edge case. When it comes to software development, these sort of expressions are known as guards, and they're there to prevent your application logic from taking place when you have a specific edge case. In many cases, when it comes to guards, it's actually the right approach to put them at the top of your function. So rather than checking halfway down where we've done some logic, we know for a fact that if we have an empty data string, we're just going to be returning zero.

So in this case, we would put the actual guard at the top of our function and just return zero at this point. For me, I find this a little more readable because you can see all of the guards at the top of the function. And in this case, we're guarding against a zero data length and just returning zero straight away. Then the rest of the code is operating under the knowledge that it's not going to be affected by any guards, i.e. it's not going to be operating in those edge cases. To show that this also works, if we go ahead and test our code again, you can see it does.

With that, we've managed to solve the current edge case by using this guard. Unfortunately, however, our code still has a number of bugs. For example, if we head back on over to the main test.go, let's go ahead and add in yet another test. This time, we'll go ahead and set to the input to be a single space. Now, our expectation is still going to be zero, but our result isn't going to match that expectation.

So let's go ahead and do input and we'll do a simple if result is not equal to once, then we'll go ahead and just copy this in. By the way, in the next lesson, we're going to make this a lot easier for us to add expectations. As you can see, it's kind of tedious at this stage. In any case, with our new test case added, if we now go ahead and test this again, you can see we're expecting zero, but we actually got two. This is yet another edge case that our code does not handle properly.

So in the next lesson, we're going to go ahead and make a couple of changes. The first is we're going to make it easier so that we can add all of these different cases into our code without having to repeat the same logic of calling the count words function and then checking the assertion. Then afterwards, we're going to go ahead and take a look at how we can actually solve some of these edge cases in a more sustainable way, before then falling upon a solution that the standard library provides us.

Before we do that, make sure to go ahead and add both the main.go and main.test.go changes to your repository. And if we take a quick look at actually what's changed, you can see that we capitalized the count words, which we'll talk about more on module three. I'm just doing it at the moment just to kind of prepare for that module. Then we added in a new test case for empty tests, which we managed to resolve, whilst also adding in a test case for our single space, which we didn't.

Normally, it's a bad idea to commit code that doesn't work or a test that doesn't work. But in our case, we're going to do it anyway. So go ahead and commit it with the message of added in two edge cases and resolved empty string. And once that's committed, I'll go ahead and see you in the next lesson.