Hello, welcome back to lesson number eight. This lesson is about defensive programming. So far, we've looked at many tools to build your program, to write code, and develop functions and code and packages and all kinds of things. But now we need to look a bit about how to make that code more reliable. Now, writing code is very well and easy, but writing code that is robust and reliable under most circumstances is a lot more difficult. The assert statement is an incredibly useful tool in your library for dealing with this. Assert is a statement that means we state it like so. There are no brackets; it is not a function. We say assert, and then we say give an expression that evaluates to true or false. So, we could have x less than 10, then comma, and then we can put a string, and this string will be the error that appears. x must be greater than 10, and we'll just add in or equal to string right. So, at the moment, we're getting a name error because we haven't defined x yet. So, let's define x. Let's make x equal to 4 now.

if we run the assert, nothing happens because x is less than 10. So, let's set x equal to 12 and run it again. You can see we're triggering an assertion error. It's saying x must be greater than or equal to 10. In other words, this is a way of raising an error specifically under a certain condition. It's like an if statement and a raise error statement rolled into one, and they're very useful. Where would you use this, you might ask. Well, a quite common location would be in some kind of function. So, let's have a function that does the fizz buzz algorithm. If I haven't mentioned it so far, fizzbuzz takes a number of some kind and says, Is that number divisible by 3? If so, say fizz. If it's divisible by five, then buzz. If it's divisible by three and five, then fizzbuzz. And if it's divisible by neither, then just return the number. So, we can say, If number visible by three and number divisible by.

five return fizz ah no fizz buzz else if number divisible by three return fizz else if number little by five return buzz else return number. There we go, this is our function. We've got fizzbuzz, there's butts. Let's see, there we go. We can get fizz buzz returned 1011, get the number back fine. This all works fine. However, what happens if we do this? We get an error because type error, not all arguments converted during string formatting, which isn't all that helpful. So, what we can do is add an assert statement. We can assert type of number is equal to int. Fizzbuzz only takes integer arguments. There we go. So, now if somebody was to call fizzbuzz with a non-integer value, we get an assertion error and a much more helpful argument. We can even add assertions to the end, so we can say assert number. Well, we can assert type number in. So, rather than saying equal to, we can say in int or string. Now, what we're saying is we get an assertion error here, but if

for some reason, something is returned that is neither an int nor a string. It will be picked up by this assertion. Now you might be wondering, Oh, but we're obviously not going to get that because we're tacking the type here and we're returning things here. Yes, that's true. However, one thing that often happens in code is that people will go away, and the code will be edited by them later on or by somebody else. Functionality will change to add in some kind of new feature, and so suddenly these assertions at the beginning, at the end, are required because things are changing in the body of the code. This is a very common occurrence, especially when extending functionality. So, that's how assertion types work. But as you can imagine, changing things in the body of the code, people might change the assertions to make to work with what they currently do. But a much better way of testing whether your function behaves as it should do is with a test. So, what is a test? Our test is just another function, really. We have tests, we

have test fizz buzz uh multiples three. So, what this test is gonna do is it's going to run for i in for item in and let's have a list of multiples of 3. So, 3, 5, 7, 3, 6, 9, 12, and then we'll go up to some other large number like 333 and -3. So, for each of those, we're going to assert that fizzbuzz of item is equal to fizz. There we go. So, now if we run this test, it passes. Nothing happens because our function will return fizz for all of those values, and that's what a test is. We basically build some kind of test where we expect to see one result, we run our function to make sure it returns that result, and then we throw an error if it doesn't. And this is what's known as a test. As you can imagine, writing tests for your code is incredibly useful. In fact, most major code boxes will have a suite of tests, a suite which is often many, many tests long. It's not uncommon uh for

projects like pioneer pdl to have test libraries that have hundreds of tests. In fact, I think it has almost upwards of 300 tests because tests can ensure that your code behaves exactly as it is needed to. Once you have a lot of things going on in your code, if it's longer than a few hundred lines, then that means that you've got a load of behavior that your code does. When you want to change it and add new behavior, you want to make sure that you haven't broken the old behavior. You want to make sure that you haven't inadvertently changed something somewhere else in the code. The best way to do that is to have a series of tests that run through your code and basically check that the functionality is there. That means that when you start working on it, you can run a test to make sure that nothing's been broken by anyone else. Then you can do your edits. Then you can run the tests again to make sure that you have maintained the functionality that you wanted to.

and we can show that with this fizz buzz calculator because we've got fizzbuzz multiples of three. We could do another one for multiples of five where we say uh 5, 10, r, but we could put 15. 15 obviously won't work because it's multiple of three and a multiple of five, so skip that twenty, twenty-five, five, five, five minus five, and then say that this should be buzz. So you might be wondering, okay, well, how are we going to ah, we've got an assertion error. What's going on? It means that one of our numbers is not returning the correct result. So we can do this. Let's say add a thing saying um, we're going to add an f-string, which is a formatted string. I would recommend looking this up. This is just saying which item went wrong. So 555, this means that 505 is probably also divisible by three. So let's change it to 55. There we go. Now it's passing. Okay, so we've got two tests for our function. What if we wanted to expand the fizzbuzz?

function if we wanted to expand and make it fizzbuzz bang. Fizzbuzz bang is an extension of fizzbuzz whereby we go up to multiples of seven become bang, or we could even say fizzbuzz. What if we did fizzbuzz but with characters as well? So, there is this other extension to the game where you say fizzbuzz for every character that matches the numbers. So, for example, 13 isn't divisible by 3 or 5, but you would say fizz because it's got a 3 in it. Suddenly, things get more complicated. Suddenly, things are getting a lot harder to program and thus a lot harder to make sure that everything works in every scenario, and that's where tests come in. Finally, I should talk about how so far we've been writing tests after we've written the function. This isn't that uncommon. This is quite a standard way of doing things. However, it has been shown time and again that the best way to write functions is to write the tests first, and we write the test first. That's

called test-driven development. We define tests beforehand and then use that to think about exactly what we think should happen. Take it for this fizz buzz, for example. Imagine we hadn't written fizz buzz yet. We write fiz bars multiples of five, so we have these assert statements. These have to be true. Then we could do this bars multiples of five and three and then say all of these have to be true. So what else is a multiple of five and a multiple of three? Okay, well, there's some easy ones. And then let's say minus 15. What do we think zero should be? Should zero be a multiple of five and three? Oh, ah, assertion error 15. So we've got a problem. You see, we've written our code. 15 should return fizzbuzz. Ah, but we didn't write it properly, did we? So we should have done fizz buzz here rather than just buzz. There we go. Let's try it again. There we go. They're all passing. So zero is also a multiple of five and three. This forces us to think about exactly

what we would do or what we want the code to do in that scenario. If we write the test first, we can say, Okay, well, 15, 30, 60, -15, they should all be fine, but zero should. Should zero be fizzbuzz? Should zero be zero? Technically, it's divisible, but do we include it? Should it be counted? This is what test-driven development leads us to think. It forces you to outline the specification in advance, and it's a very powerful tool. Alright, have a go at the exercises and see how you do.

Defensive Programming — Lesson 8

Defensive Programming — Lesson 8

스크립트