Test Driven Development.

Ever Wondered how to do tests in python and what they really are? (Test Driven Development in python), quite hard as some might say. This is your one stop blog in understanding what it is and it’s work-flow.
Test driven development is a software development technique where you get to write tests first, before the code itself. This is usually a repetitive cycle: where the functionality is written from specific test cases. With the tests, they get to fail as you write code to being guided with the failures. So we improve the software to pass new tests only. As opposed to the software development process that allows adding code that is not proven to meet requirements.
This way, the test guides you on how to write the code.

We will be using the unittest module for the example in this blog. The unittest test framework is python’s xUnit style framework.

It is a standard module that you already have if you’ve got python version 2.1 or greater

So far we know the tests do nothing and we now want to add the code to test  now with the above code you can try run it to see the output please note that the code will fail.

Now when you run the test at first you will we will create a python file to solve the module import error. Remember we are using the test as a guide for creating our code/app/(whatever you may call it). So repeatedly, we run the code as we get the errors/failures and get to know what to do next. Even though we know what the code actually does, it’s best to know do the development this way.

Another example is when you are told of an assertion error of expected value 10, In this case when you return the value 10 the test will pass but it’s not efficient enough, thus you will need to add more tests for this in order to make your code most efficient.

Another easy-to-understand example is when we get an error due to the non-existence of the add_numbers function/method you will then go and create the method in the MathOperations class. Step by step until you have the code done.

Assertion statements in unittest include:

  assertEqual(first, second, msg=None), (# asserts that first == second)
    assertNotEqual(first, second, msg=None), (# asserts first != second)
    assertTrue(expr, msg=None), (# asserts that expr returns True)
    assertFalse(expr, msg=None), (# asserts that expr returns False)
    assertIs(first, second, msg=None), (# asserts that first is in second)
    assertIsNot(first, second, msg=None), (# assert first is not second)
    assertIsNone(expr, msg=None), (# assert expr returns None)
    assertIsNotNone(expr, msg=None), (# assert expr’s return value isn’t None)
    assertIn(first, second, msg=None), ( # assert fist is in second *arrays*)
    assertIsInstance(obj, cls, msg=None), ( # assert that obj is of type cls)
    assertNotIn(first, second, msg=None),(# assert first isn’t in second*arrays*)
    assertNotIsInstance(obj, cls, msg=None).args, \**kwargs), ( #assert that obj is of type cls )

It is also possible to check that exceptions and warnings are raised.
To do this, we manly use, assertRaises(exc, fun, *). The above list of assertion statements are the most used, but we also have others that are not mentioned in this post.

class MathOperations():
   def __init__(self):
   	pass
    
  def add_numbers(self, a, b):
   return a+b

  def multiply_numbers(self, a, b):
   return a*b

  def subtract_numbers(self, a, b):
   return a-b

In case of any questions am just a contact away, and please feel free to view more about me on my site adiós {*.’}.
One clap, two clap, forty {you know the drill}