Coffee Analogy

Let's start with an example of making a perfect coffee:

• What does it take to make a perfect coffee (Lets Think)

1. Checking for this coffee is perfect ---> Testing
2. Always make sure the measures after every step ---> Defensive Programming
3. Making coffee in a coffee machine eliminates all chances of imperfections That eliminates ---> all sources of imperfections

Defensive Programming

• That's writing code defensively
• Writing Modular code for better clarity
• Writing docstrings( specifying input and output of that function) for functions
• Checking conditions on input/output ( assertions )

Testing / Validation

• Testing out the program that is checking/ validating inputs and outputs ( comparing ).
• Simply check whether the programming is working.

Debugging

• Going through the code step-by-step to check it's working and finding problems.
• It shows the semantic steps of working the code.

TESTING

Before Testing the program

1. Ensure that the code works
2. Check for Runtime errors. i.e Is it semantically correct, is it syntactically correct?

3. Interpreter finds these runtime errors for you pretty easily

4. Have a set of inputs and expected output for verification in testing

Classes of Testing

1. Unit Testing

• It's the first class of testing where you test each block/unit of your code.

2. Regression Testing

• In this class, we add tests to bugs as we find them
• Check for the reintroduced errors which we found in the first step

3. Integration Testing

• In this final class of testing we check the entire program and its working.
• Developers tend to rush to do this

Testing Approaches

1. Instinct-based testing that is having an intuition about the natural boundaries of the problem

def is_bigger(x, y):
""" Assumes x and y are ints
Returns True if y is less than x, else False """

here you can't judge about natural boundaries of the above problem so what we do here is, perform tests because the more you test the lower the chance to have bugs.

and there are some better options for testing below:

2. Black box testing

• It's apparently testing the program or block of code without looking at the code
• For example, we just have to see docstring in the function to test it
• This can be done by any other person instead of the programmer itself to avoid implementer biases
• Even if the implementation changes the testing can be reused here.
• Here you explore paths according to the given specifications i. Like testing in possible random natural partitions ii. Also testing the boundary conditions including data like empty tuples, empty lists, etc

3. Glass Box Testing

• In this type of testing we go through the code ( unlike black box ) and use path-complete method of testing
• Path-complete means testing every single possible path/direction the program can go.

• But there are some drawbacks to this type of testing:

  i. we could go through the loop many times ii. there may be some paths left to test ---> missing paths

• To overcome these drawbacks we should these guidelines:

Also check for all the boundary conditions to overcome the missing path problem