Test-Driven Development In Python // The power of red-green-refactor

https://www.youtube.com/watch?v=B1j6k2j2eJg&list=PLC0nd42SBTaPYSgBqtlltw328zuafaCzA&index=2&ab_channel=ArjanCodes 

TDD is a term coined in 2002 by kent beck in his book Test-Driven Development By example.

 

2. Five Steps of TDD

    a. Step 1 : Write Tests

        i. Whey you add a new feature, you basically start by writing the tests that only pass if the feature specifications are met. This is actually a very important benefit of tdd that it forces you to think about the requirements before you start actually building something.

    b. Step 2 : Run the tests

         i. Make sure they all fail.

         ii. It's important that these tests fail because you want to check that you're actually adding something new and that the tests are properly testing that part.

    c. Step 3 : Write the Simplest code that these tests pass .

    d. Step 4 : MAKE ALL Tests pass.

    e. Step 5 : Refactor and Improve.

 

3. Why we use assertAlmostEqual 

-> Because of rounding errors with float 

def test_employee_payout_no_commission_no_hours(self):
    """Whether payout is correctly computed in case of no commission and no hours worked."""
    self.assertAlmostEqual(self.arjan.compute_payout(), 1000.0)

 

4. Pros and Cons of TDD cycle

 

Pros

    a. It forces developers to think about requirements first and that

    b. Sentence a means you need to make sure that your feature is defined well and that you know exactly what it needs to do because otherwise you can't write the tests. 

    c. This forces developers to think about their interfaces first as opposed to start coding away.

    d. TDD is that even though you probably have to write more code, it might save you a lot of time overall because you're detecting bugs much earlier.

    e. Tdd can make you probably know that if you're debugging your code. This might sometimes take a long time before you find a problem and having those tests there is really going to help you find those bugs sooner and that will save you time.

    f. If you start by writing tests you force yourself to write code that's easily testable and that means you'll be more inclined to use design principles and design patterns to write code. That's easy to extend and easy to separate from other parts of the application and that just make your code in the end much easier to maintain.

 

Cons

    a. Writing and maintaining lots of tests is going to take time. If you're working at a stable company who knows what their product is who knows what their users want and this is not particularly an issue because anyway it's going to help you with debugging faster and keeping the system stable.

    b. If you're working at the startup though in particular an early stage one, then adding all those tests might become a big overhead.

    c. It's going to be a waste of your time if anyway you're going to completely change your product and throw everything away that you did. So you have to find a careful balance there.

    d. If you've written many passing unittest you might have created a false sense of security for yourself. And you may not put as much efforts as is needed in other testing activities such as integration testing or end-to-end testing 

    e. Often the developer that writes the tests is also the developer that writes actual code and that may lead to blind spots. So it's always a good idea that especially if you are in a team that you separate the work of writing tests and writing the actual code between different team members. Because then you have less chance of developing these blind spots.

    f. Another possibility if you don't do that is that developer misinterprets a part of the design and implements the feature in the wrong way but then also it in wrong way. And then you won't find it out until perhaps it's too late or the client start complaining that it doesn't work as it supposed to.

5. Three Tips for unittest

    a. Watch out for reusing the same data in multiple tests

        i.  Ideally you want your tests to be completely decoupled, completely independent from each other.

        ii. You don't want a change that you did in one test to affect the results of another test because then it becomes extremely hard to debug.

        iii. So don't use these kind of global instances and reuse them in different tests.

  

    b. You don't need to test python built-in functions

        i. 

 

    c. If you write a test, compare your output with a fixed value.