 So let's dive into unit testing now and the first question is what is the unit we are testing and very often we are talking about classes as a single unit in object-oriented programs and functions or operations so kind of a single unit of computation and there are different strategies on how do you test In order to find defects because if you remember defect testing is about trying to cover as much as possible And if you consider for example a class, so I just use you mail here you Well Have a class name You have a certain number of attributes for example you might have something that was called an ID Maybe a name so different kinds of attributes and then you have operations do a Do be and they might have of course parameters return values and so on So the strategy for testing a class if this is our unit is to say well We should try to set Modify and Read all of the attributes right can we read them? Can we somehow set them get them modify them? Is that possible in the way we would like to do and of course maybe some of them should not be settable then? We should not test that maybe for operations we try to test them well we should call all of these operations and We should try to test them with different input essentially, so if they have parameters for example, is there Anything we can vary there We can for example put regular Kind of expected input in there, but we can also do unexpected or simply wrong erroneous cases Input null undefined or so on and then finally if we look at the class as a whole Classes sometimes not always, but if you instantiate a class it sometimes might have a state That it can change over time. So then this is also something we would like to cover. So can we vary the state so that we actually visit the class in all different States and see whether it's possible now some heuristics in particular for for kind of setting values or for input parameters are a number of things that typically go wrong and Some of them is for example zero or one Length sequences so imagine you have as an input as a parameter you have an array for example that you put in Typical bugs include Issues where the the code assumes that there is at least one or at least two elements So for example in the code you might have a you might access the first element without even checking that there is one So by writing tests that that Include these cases you very often find errors So that's the heuristic that's simply based on typical mistakes that happen Other things are for example, buffer overflows. That's again a very common thing. So you try to simply put Basically put too much into an operation Your implementation expects that it will be a top thousand elements and you put something with ten thousand in maybe something goes wrong And you will get some errors very similar is To use elements at at the end of a range so for example Assume that you have an integer value What happens in most programming languages if you take the maximum integer number and you add one is that it Wraps around and it starts at the bottom. So the question is is the operation able to handle that and Well, this is again something that happens very often that people forget about that. So by using very large or very small Elements, this is something that typically gets exposed. So max minimum elements in a certain data type Is something and then finally this is something I have already mentioned a sort of the the Undefined things so for example null undefined Depending on the programming language you use it could be different kind of things that you could put in there So that's sort of trying out different inputs that from experience often lead to mistakes so these are mistakes we often make in programming and This often sounds trivial. So when you present this it's like, yeah, who wouldn't make these mistakes But these things happen and they even happen to professional programmers that have done these over the years Simply because it's sometimes so easy to forget. So it's it's really even though these heuristics are quite basic It's quite a powerful instrument to follow these So don't underestimate them Then the final concept I would like to mention here before we we get on to the next video is the concept of partition testing so very often you have an input That you can divide into number of classes for example again, let's assume we have an integer for example for minus 10 till 0 for 1 till 100 and For everything over 100 you expect kind of three different outputs For example for this you kind of expect that the the return value will be let's say true You expect that for this it will be false And you expect that here you actually get something like I don't know voyage you might get an exception or something else Again, maybe depends on the programming language And so basically instead of having to test all possible integer values You actually have Partitioned your input space into different groups into different boxes or classes And then the strategy would be to say well you choose a typical value from each of these classes So we write a test with input minus 5 10 200 typical elements And we check whether we actually get the expected results and additionally because that's a case where arrows happen very often We check the edges of our partitions the borders So how about we put zero in we put one in we put a hundred a hundred one in Simply because similar to this zero in one length it happens so easily that for example in your code instead of a larger than a hundred You suddenly have a larger equals Mistakes that happen very often but basically suddenly instead of having to write basically a number of Tests that is equal to the number of integers you have broken this down into three classes So you basically need to test Three different values plus maybe the edge values which is much much fewer tests than if you try to somehow go through there So that's a strategy if you can apply that by basically discretizing breaking down your input space into Boxes into different classes and of course the integer case is very easy This might be trickier you have a string as an input if you have a number of different parameters So of course in practice, that's not always easy But at least it helps you to think about what might be good cases that I can test So this is a concept that is called partition testing that is Something that can help you and overall these heuristics partition testing and the strategy how to test the class That at least gives you some kind of idea where to start if you're sitting and thinking about What should I write what kind of unit tests so overall this helps you to cover a large extent of cases And now in the next video we'll talk more about this coverage. What does it actually mean to cover a lot of code?