DEV Community: Subhodeep Sarkar

Diving into Serverless: Azure Durable Functions in Node JS (+Troubleshooting)

Subhodeep Sarkar — Wed, 16 Oct 2024 16:26:31 +0000

Serverless Functions

Serverless might sound like your code runs without a server but it is not like that 😂. In Azure, Functions are tiny pieces of code that run based on a trigger or input and have an output. It is called serverless because you do not have full control over its underlying OS, network, storage or infrastructure.
You might compare it with other PaaS offerings like Azure App Service but there's a difference. Azure App Service will always be running and readily available. Also, you will be charged for the entire time the server is running irrespective of whether people are using it or not.
Azure Functions on the other hand are not always active. They only run when it is triggered based on some event and you are charged only for the time your code runs and that's it. It is great for doing atomic work e.g. renaming, moving or creating and filling files.
The problem with Azure Functions is that it is stateless, meaning it does not remember the inputs, outputs, variables, other function calls etc.

Stateful Functions

This is where the durable functions come in. These functions can store state in a storage account (by default in a file share) and can reuse them. There are several patterns in which you can build durable functions.

Generally speaking, they have 3 components:

1. Orchestrator Client: It is the primary function that is called. This activates the orchestrator function.

2. Orchestrator: The function that acts like the opera head and decides what are things to be done and in which order they should be done (kind of like Azure logic apps but logic apps are all about drag and drop whereas this is just code). This orchestrator function calls any number of activity functions asynchronously.

3. Activity: This is the atomic level function that actually performs some task.

Durable Function Patterns

There are multiple patterns in which you can develop the durable functions workflow.

- Function chaining: One function calls another function and so on.

- Fan-Out/Fan-In: A function calls multiple functions in an async fashion and waits for all of them to be completed and then it moves and narrows down to one function.

- Asynchronous API pattern: A function starts some other function and another function checks if the work is completed at regular intervals in an async fashion.

- Monitor pattern: A function calls and waits for an event to happen and when it occurs it triggers another function.

- Human interaction pattern: A function waits for a human to perform an action and in case there is a timeout it triggers some other function.

Demonstration

Go ahead and create a function app from the marketplace, the plan should be consumption-based.

Select a subscription, and a resource group (or create a new one) and set the function app name. Btw, the function app name has to be unique globally as this can be accessed from the internet. Select the stack as Node js, version as 20 LTS and OS as Windows and your preferred region.

Keep clicking next to keep the default values for the rest of the fields and finally create the function app.

Troubleshooting #1

Once you are done creating the function app, you might get a warning that "dynamic scaling is not enabled".

Spoilers! If you go ahead and create a durable function from the portal you will complicate things and will get more errors like this one below

What's happening? 🕵
Logically speaking, the functions that you will be creating under the function app are basically code, that is stored in files right? And it has to be stored somewhere right? This "somewhere" is a storage account that is not yet linked with the Azure function app and thus nothing will work because it cannot store the files. Also as I stated earlier, you need a storage account where the state of the durable functions will be stored for later use.

Solution ✅
What you need to do is create an Azure Storage Account in the same region as your function app and in the networking section make sure it is publicly accessible.

Go to data storage > file shares and create a file share

Copy and paste the file share name in Notepad or any other text editor as you will be needing this later.

Once you are done with this, go to Security + Networking > Access Keys and copy one of the connection strings

paste it in Notepad or any other text editor as you will be needing this later.

Now come back to your function app and go to settings > environment variables -- App Settings create new.

The first setting name would be "AzureWebJobsStorage" and the value would be the connection string of your storage account.

The next setting would be "WEBSITE_CONTENTAZUREFILECONNECTIONSTRING" and the value would again be the connection string of your storage account.

The third and final setting would be "WEBSITE_CONTENTSHARE" and the value would be the file share name inside your storage account.

Now click on apply and confirm.

Congratulations! You have just set up a storage account that will allow dynamic scaling and let your durable functions store state. You can visit the overview page of your function app and the error is now gone

You can go to the default domain of your function app and see that the host is up and running!

After this I went ahead and created all the required durable functions and this was a mistake 😭 Please don't repeat the mistake and wait till you reach Troubleshooting #3 after that follow the steps to create durable functions

Troubleshooting #2

On various tutorials, you will be told to open the console and install "durable-functions" which is a required package and then simply go ahead with durable functions. Unfortunately, it did not work for me. Instead, I got a 500 internal server error.

Upon searching the logs from the invocations tab I got this

Pasting the error so that you can view this too.

Result: Failure Exception: Cannot read properties of undefined (reading 'extraInputs') Stack: 
TypeError: Cannot read properties of undefined (reading 'extraInputs') at
Object.getClient (C:\home\site\wwwroot\node_modules\durable-functions\lib\src\durableClient\getClient.js:11:40) at module.exports 
(C:\home\site\wwwroot\DurableFunctionsHttpStart\index.js:4:23) at t.InvocationModel.<anonymous> 
(C:\Program Files (x86)\SiteExtensions\Functions\4.36.0\workers\node\dist\src\worker-bundle.js:2:63453) at Generator.next (<anonymous>) 
at C:\Program Files (x86)\SiteExtensions\Functions\4.36.0\workers\node\dist\src\worker-bundle.js:2:61778 at new Promise (<anonymous>) at p 
(C:\Program Files (x86)\SiteExtensions\Functions\4.36.0\workers\node\dist\src\worker-bundle.js:2:61523) at t.InvocationModel.invokeFunction
(C:\Program Files (x86)\SiteExtensions\Functions\4.36.0\workers\node\dist\src\worker-bundle.js:2:63260) at y.<anonymous> 
(C:\Program Files (x86)\SiteExtensions\Functions\4.36.0\workers\node\dist\src\worker-bundle.js:2:39015) at Generator.next (<anonymous>)

What's happening? 🕵
Upon searching the internet I got to know that if I just do npm install durable-functions it will simply install the latest package which at the time of writing is 3.1.0. This version is however not compatible with Azure functions v4. So I had to downgrade it to 2.0.0 and that error was gone.

Solution ✅
Go to Development tools > console

_(if you have already installed the latest package just uninstall it using npm uninstall durable-functions)
_

now install the correct version of the package npm install durable-functions@2.0.0 and check the contents of package.json using cat package.json

Troubleshoot #3

Even after doing all these, I was still getting a 500 internal server error and I checked the logs again under the invocations

Pasting the error

Result: Failure Exception: Worker was unable to load function DurableFunctionsHttpStart: 
'Cannot find module 'moment' Require stack: - 
C:\home\site\wwwroot\node_modules\durable-functions\lib\src\task.js - 
C:\home\site\wwwroot\node_modules\durable-
functions\lib\src\durableorchestrationcontext.js - 
C:\home\site\wwwroot\node_modules\durable-functions\lib\src\orchestrator.js - 
C:\home\site\wwwroot\node_modules\durable-functions\lib\src\classes.js - 
C:\home\site\wwwroot\node_modules\durable-
functions\lib\src\index.js - 
C:\home\site\wwwroot\DurableFunctionsHttpStart\index.js - C:\Program Files 
(x86)\SiteExtensions\Functions\4.36.0\workers\node\dist\src\worker-bundle.js - C:\Program Files

What's happening? 🕵
As you can tell from the error log, a package 'moment' is missing and it is a required package.

Solution ✅
Simply open the console again and install 'moment' using npm install moment and verify the contents of package.json

And this error is gone too!

Congratulations! We are done with all the errors and now we are ready to create the durable functions

Creating Durable Functions

Start by creating the first component, the Orchestrator Client.

Type 'durable' in the search bar and select 'durable functions HTTP starter'

Rename the function as per your wish, the authorization level should be set to function and create it

Now we will create the orchestrator. Go back and in a similar way select "durable functions orchestrator" and rename it as per your wish.

Finally, we will create an activity. Go back and in a similar way select "durable functions activity" and rename it as per your wish

We are done!

Now let's understand the code in a bit more detail. See the code for every function by clicking on it and going to the Code + Test tab

1. Orchestrator Client (myClient)
This functions will trigger the Orchestrator upon getting a HTTP request. In line 5 client.startNew() will call the Orchestrator function and req.params.functionName will contain the name of the Orchestrator function which in my case is 'myOrch'. We will see how we will pass in the function name to the orchestrator client.

const df = require("durable-functions");

module.exports = async function (context, req) {
    const client = df.getClient(context);
    const instanceId = await client.startNew(req.params.functionName, undefined, req.body);

    context.log(`Started orchestration with ID = '${instanceId}'.`);

    return client.createCheckStatusResponse(context.bindingData.req, instanceId);
};

2. Orchestrator (myOrch)
This is the orchestrator function which will take care of calling activity functions. In line 7,8 and 9 "Hello" is the name of the activity function that will be called. (If your activity function has some different name then replace Hello with it) "Tokyo" in line 7 is the argument that will be passed on to 'Hello'. Similarly "Seattle" and "London" would be passed on to 'Hello' in lines 8 and 9. It will wait for all the three responses from 'Hello' and will push each response into the outputs[]. This is why we call this a 'Fan-out' (expanding) as 3 functions are called from 1 orchestrator function and then all the responses are collected by the orchestrator function and returned as a response thus 'Fan-in' (shrinking). Finally outputs[] would have ["Hello Tokyo!","Hello Seattle!","Hello London!"]

const df = require("durable-functions");

module.exports = df.orchestrator(function* (context) {
    const outputs = [];

    // Replace "Hello" with the name of your Durable Activity Function.
    outputs.push(yield context.df.callActivity("Hello", "Tokyo"));
    outputs.push(yield context.df.callActivity("Hello", "Seattle"));
    outputs.push(yield context.df.callActivity("Hello", "London"));

    // returns ["Hello Tokyo!", "Hello Seattle!", "Hello London!"]
    return outputs;
});

3. Activity (Hello)
This is the activity function. It will be called by the orchestrator function. It is very simple. It will just take the argument passed from the orchestrator and will format it and return. For example in line 7 of the orchestrator we were calling activity using outputs.push(yield context.df.callActivity("Hello", "Tokyo")); so we will get Hello Tokyo!

module.exports = async function (context) {
    return `Hello ${context.bindings.name}!`;
};

Let's see this in action!
First, open the orchestrator client (myClient) and go to Code + Test tab. Click on 'Get function URL' and copy the default(function key) URL.

https://test746234.azurewebsites.net/api/orchestrators/{functionName}?code=L9cALt2iP5V39M023c1I9lALDlpumzXurTUNzut4S9cTAzFujCPDOA%3D%3D

Now replace the {functionName} with your orchestrator function name which in this case is myOrch. So your URL should look like this

https://test746234.azurewebsites.net/api/orchestrators/myOrch?code=L9cALt2iP5V39M023c1I9lALDlpumzXurTUNzut4S9cTAzFujCPDOA%3D%3D

Now paste this in a browser and open it. You will see a bunch of URLs.

Now copy the URL of statusQueryGetUri and paste it in the browser and open it.

Voila! Congratulations! We got our expected results back! The results might or might not be in the same order as they are called as these called asynchronously.

Thank you for reading till the end. Hope this was useful for you :)

Generating Fake bulk data using Factory-Boy in Python

Subhodeep Sarkar — Wed, 24 Jul 2024 16:43:52 +0000

You often need fake data to test against. You can, of course, use some sample data in your tests. But what if you need hundreds of records, or even thousands of records, of test data? Then it can get tedious to create and maintain. Sometimes you just need a fake version of a class in your program but you want to have it be realistic data that behaves like the real class. Factories and fakes make this all possible.

In this article we will be using Factory-boy a package in Python for generating fake data.

Please make sure that you install the correct version of factory-boy using the command pip install factory-boy==2.12.0

Let's try to generate some fake data using factory boy

import factory #import factory-boy
name = factory.Faker('name') #create Faker object with 'name' provider
for _ in range(5):
    print(name.generate()) #generate and print 5 unique names

Results:

factory.Faker() accepts an argument which is called provider and is used for generating the type of data e.g 'name' provider will be used for generating names, 'email' provider will be used for generating email etc.
Let's try using some more providers

import factory #import factory-boy
name = factory.Faker('name') #create Faker object with 'name' provider
country = factory.Faker('country') #create Faker object with 'country' provider
email = factory.Faker('email') #create Faker object with 'email' provider

for _ in range(3):
    print(f'''
My name is {name.generate()}
I live in {country.generate()}
Reach out to me at {email.generate()}''')

Results:

Along with Faker class, factory-boy has another module which is Fuzzy, let's take a look at how it works

import factory #import factory-boy module
import factory.fuzzy #import fuzzy module
name = factory.Faker('name') #create Faker object with 'name' provider
gender = factory.fuzzy.FuzzyChoice(choices=['girl','boy']) #create fuzzyChoice object which selects from the given options
grade = factory.fuzzy.FuzzyFloat(30,80) #create FuzzyFloat object which generates a random float number between the lower and upper limit
age = factory.fuzzy.FuzzyInteger(12,18) #create FuzzyInteger object which generates a random float numbeer between the lower and upper limit

for _ in range(3):
    print(f'''My name is {name.generate()}, I am a {gender.fuzz()} 
I got a grade of {grade.fuzz():.2f}% and my age is {age.fuzz()}
''')

Results:

To learn more about the different Classes in fuzzy module and the various options for providers for Faker visit: https://factoryboy.readthedocs.io/en/stable

Now that we know how Factory-boy can mimic data, let's try mimicking data models which are generally used for creating database tables for applications such as Flask, Django etc.
For this project make a requirements.txt and paste the below contents and then install all the required packages using pip3 install -r requirements.txt

# Pin dependancies that might cause breakage
Werkzeug==2.1.2
SQLAlchemy==1.4.46

# Dependencies for this project
Flask==2.1.2
Flask-SQLAlchemy==2.5.1

# Testing dependencies
nose==1.3.7
pinocchio==0.4.3
coverage==6.3.2
factory-boy==2.12.0
pylint==2.14.0

And since we would be running unit tests using nosetests please review my previous article - "Test-Driven Development in Python using Unittest and Nose" (https://dev.to/h4ck3rd33p/test-driven-development-in-python-using-unittest-and-nosetest-24ck)

create a setup.cfg file for nosetests configuration and paste the below contents

[nosetests]
verbosity=2
with-spec=1
spec-color=1
with-coverage=1
cover-erase=1
cover-package=models

[coverage:report]
show_missing = True

now create two folders models which will contain the data model in account.py and the basic setup in __init__.py and tests which will contain the factory model which will mimic the actual model in factories.py and the associated unit tests for testing the application in test_account.py.
Eventually your folder structure should look like this:

.
├── models
│   ├── account.py
│   └── __init__.py
├── requirements.txt
├── setup.cfg
└── tests
    ├── factories.py
    └── test_account.py

2 directories, 6 files

Let's say we need to test a data model that handles customer accounts. We'll start by creating this data model. We will use a popular object relational mapper called SQLAlchemy and so we create a db instance of the SQLAlchemy class. Now we build our model. We create a class called Accounts that inherits from the base model of SQLAlchemy. Now we can add our columns, which will be represented as class variables. We add an id. It will serve as a non-information bearing key so we label the id as the primary key. We add a name as a string and an email field as a string. We also add a phone number as a string. We make that phone number optional, so we set nullable to True. Let's add a Boolean field to determine if this account is disabled, and let’s make the default False. And finally, we'll add a date joined column as a DateTime and make it optional as well.

models > __init__.py

"""
Data Models
"""
from flask import Flask
from flask_sqlalchemy import SQLAlchemy

app = Flask(__name__)
app.config['SQLALCHEMY_TRACK_MODIFICATIONS'] = False
app.config['SQLALCHEMY_DATABASE_URI'] = 'sqlite:///test.db'
db = SQLAlchemy(app)

models > account.py

"""
Account class
"""
import logging
from sqlalchemy.sql import func
from models import db

logger = logging.getLogger()


class DataValidationError(Exception):
    """Used for an data validation errors when deserializing"""


class Account(db.Model):
    """ Class that represents an Account """

    id = db.Column(db.Integer, primary_key=True)
    name = db.Column(db.String(64))
    email = db.Column(db.String(64))
    phone_number = db.Column(db.String(32), nullable=True)
    disabled = db.Column(db.Boolean(), nullable=False, default=False)
    date_joined = db.Column(db.Date, nullable=False, server_default=func.now())

    def __repr__(self):
        return '<Account %r>' % self.name

    def to_dict(self) -> dict:
        """Serializes the class as a dictionary"""
        return {c.name: getattr(self, c.name) for c in self.__table__.columns}

    def from_dict(self, data: dict) -> None:
        """Sets attributes from a dictionary"""
        for key, value in data.items():
            setattr(self, key, value)

    def create(self):
        """Creates a Account to the database"""
        logger.info("Creating %s", self.name)
        db.session.add(self)
        db.session.commit()

    def update(self):
        """Updates a Account to the database"""
        logger.info("Saving %s", self.name)
        if not self.id:
            raise DataValidationError("Update called with empty ID field")
        db.session.commit()

    def delete(self):
        """Removes a Account from the data store"""
        logger.info("Deleting %s", self.name)
        db.session.delete(self)
        db.session.commit()

    ##################################################
    # CLASS METHODS
    ##################################################

    @classmethod
    def all(cls) -> list:
        """Returns all of the Accounts in the database"""
        logger.info("Processing all Accounts")
        return cls.query.all()

    @classmethod
    def find(cls, account_id: int):
        """Finds a Account by it's ID
        :param account_id: the id of the Account to find
        :type account_id: int
        :return: an instance with the account_id, or None if not found
        :rtype: Account
        """
        logger.info("Processing lookup for id %s ...", account_id)
        return cls.query.get(account_id)

Now let's create the fake class that mimics the original Account class. Let's name it AccountFactory. Also make a inner class Meta and make an attribute model and set it to Account which will let Factory-Boy know exactly which data class it has to mimic and thus AccountFactory will now have all the methods automatically that Account class has.

tests > factories.py

"""
AccountFactory class using FactoryBoy
"""
import factory
from datetime import date
from factory.fuzzy import FuzzyChoice, FuzzyDate
from models.account import Account

class AccountFactory(factory.Factory):
    """ Creates fake Accounts """

    class Meta:
        model = Account

    id = factory.Sequence(lambda n: n)
    name = factory.Faker("name")
    email = factory.Faker("email")
    phone_number = factory.Faker("phone_number")
    disabled = FuzzyChoice(choices=[True, False])
    date_joined = FuzzyDate(date(2008, 1, 1))

id = factory.Sequence(lambda n: n) will generate continuous sequence of numbers 0,1,2...

Now let's write the unit tests for testing our AccountFactory

Test-fixtures: These are methods that are run to set up the state of the system before and after running test cases.

setUpClass(cls): This is used to set the system state before running any test cases in the class. In our example, it is creating the DB and the tables.
tearDownClass(cls): This is used to clean up the system after running all the test cases in the current class. In our example, it is deleting any remaining test data and disconnecting from the database.
setUp(self): This is used to set up the system before running an individual test case. In our example, it is deleting the data and saving it.
tearDown(self): This is used to reset the system state after running an individual test case. In our example, it is closing the current database session.
setUpAll: This is used to set up the system state before even going into any class. We haven't used this in our example
tearDownAll: This is used to reset the system state after finishing with all the classes. We haven't used this in our example

tests > test_account.py

"""
Test Cases TestAccountModel
"""

from random import randrange
from unittest import TestCase
from models import db
from models.account import Account, DataValidationError
from factories import AccountFactory


class TestAccountModel(TestCase):
    """Test Account Model"""

    @classmethod
    def setUpClass(cls): #Runs before running any unit test
        """ Create table """
        db.create_all()  # make our sqlalchemy tables

    @classmethod
    def tearDownClass(cls): #Runs after running all the tests
        """Delete test data and Disconnext from database"""
        db.session.query(Account).delete()
        db.session.close()

    def setUp(self): #Runs before running every individual test
        """Drop the table"""
        db.session.query(Account).delete()
        db.session.commit()

    def tearDown(self): #Runs after ruunning every individual test
        """Remove the session"""
        db.session.remove()

    ######################################################################
    #  T E S T   C A S E S
    ######################################################################

    def test_create_all_accounts(self):
        """ Test creating multiple Accounts """
        for _ in range(10):
            account = AccountFactory()
            account.create()
        self.assertEqual(len(Account.all()), 10)

    def test_create_an_account(self):
        """ Test Account creation using known data """
        account = AccountFactory()
        account.create()
        self.assertEqual(len(Account.all()), 1)

    def test_repr(self):
        """Test the representation of an account"""
        account = Account()
        account.name = "Foo"
        self.assertEqual(str(account), "<Account 'Foo'>")

    def test_to_dict(self):
        """ Test account to dict """
        account = AccountFactory()
        result = account.to_dict()
        self.assertEqual(account.name, result["name"])
        self.assertEqual(account.email, result["email"])
        self.assertEqual(account.phone_number, result["phone_number"])
        self.assertEqual(account.disabled, result["disabled"])
        self.assertEqual(account.date_joined, result["date_joined"])

    def test_from_dict(self):
        """ Test account from dict """
        data = AccountFactory().to_dict()
        account = Account()
        account.from_dict(data)
        self.assertEqual(account.name, data["name"])
        self.assertEqual(account.email, data["email"])
        self.assertEqual(account.phone_number, data["phone_number"])
        self.assertEqual(account.disabled, data["disabled"])

    def test_update_an_account(self):
        """ Test Account update using known data """
        account = AccountFactory()
        account.create()
        self.assertIsNotNone(account.id)
        account.name = "Rumpelstiltskin"
        account.update()
        found = Account.find(account.id)
        self.assertEqual(found.name, account.name)
        self.assertIsNotNone(account.id)
        account.name = "Rumpelstiltskin"
        account.update()
        found = Account.find(account.id)
        self.assertEqual(found.name, account.name)

    def test_invalid_id_on_update(self):
        """ Test invalid ID update """
        account = AccountFactory()
        account.id = None
        self.assertRaises(DataValidationError, account.update)

    def test_delete_an_account(self):
        """ Test Account update using known data """
        account = AccountFactory()
        account.create()
        self.assertEqual(len(Account.all()), 1)
        account.delete()
        self.assertEqual(len(Account.all()), 0)

Read the comments to understand more about the test cases. Now let's run nosetests

Congratulations! All the test cases have been passed and hence we can conclude that our AccountFactory works exactly like Account class and have tested the application using fake data using Factory-Boy!

Test-Driven Development in Python using Unittest and Nose

Subhodeep Sarkar — Fri, 28 Jun 2024 15:36:47 +0000

Test-driven development implies that we first write unit tests for our modules before writing the module itself. This way we know what we expect from our function and then write the function so that it passes the test cases. There are a total of 3 steps involved in TDD (Test-Driven Development).

Red - You write test cases first which fails
Green - You then write just enough code that passes the test cases.
Refactor - Now you improve the code quality

For a demonstration of TDD, we will be writing a simple function that calculates the area of a rectangle.

def rect(length,breadth):
    return length*breadth

Although this function looks good the reality is that it is full of bugs let's try it out.

def rect(length,breadth):
    return length*breadth

print(rect(5,10)) #Output: 50 
print(rect(4.5,3.4)) #Output: 15.29
print(rect(3,"HELLO")) #Output: HELLOHELLOHELLO
print(rect(-3,2)) #Output: -6
print(rect(0,5)) #Output: 0

As we can see when we pass a string with an integer, a negative value or zero it handles them incorrectly and we get unexpected results. No side of a rectangle can have a negative value or zero nor should it accept a string value. This is where unit testing comes into place. Before writing code we first write some of the test cases.

Create a new file and make sure you add test_ prior to the name for example, if we assume our python file's name is app.py then our test file should be test_app.py.

Write the following test cases

from unittest import TestCase #import TestCase class from unittest module
from app import rect #import your rect function from app.py you wrote

class testApp(TestCase): #make a class which inherits the TestCase class
    '''Test rect function'''
    from unittest import TestCase #import TestCase class from unittest module
from app import rect #import your rect function from app.py you wrote

class testApp(TestCase): #make a class which inherits the TestCase class
    '''Test rect function'''
    def test_area_of_rectangle(self): 
        '''Test the area of a rectangle'''
        self.assertEqual(rect(5,10),50)

    def test_bad_value(self):
        '''Test if the function rejects invalid values'''
        self.assertRaises(ValueError, rect,-5,3)
        self.assertRaises(ValueError, rect,0,2)

    def test_bad_types(self):
        '''Test if the function rejects invalid types'''
        self.assertRaises(TypeError, rect,"Hello", 3)
        self.assertRaises(TypeError, rect,True, 5)

The first test case will check if the function is returning the expected result when passing good values.

This is an example of 'Happy paths' in testing which tests if the function returns the expected result.

The next two test cases check if the function handles exceptions when passed bad data.

This is an example of 'Sad paths' in testing which tests if the function's exception handlers works properly when bad data is passed.

You can either use the default test-runner that comes with Python i.e unittest.

go to the file location and type in python -m unittest discover this will run all the test cases. If the test case pass then it will show '.' else it will show 'E' along with the test case name with which failed. In our case if we run this we get:

So, two of the tests failed but the output was not so helpful. let's try another test runner nosetests

But we need few other things as well, pinocchio for organized output and coloured text and coverage for code coverage report

We need coverage to ensure that every code statement e.g if-else branches etc. are tested before pushing it to production. The code coverage should be as high as possible.

Install:
pip install nose pinocchio coverage

Troubleshooting: If you are using python 3.10 or above, then nosetests won't work directly and will give you error. So you need to make changes to the following files:
.local/lib/python3.10/site-packages/nose/suite.py
.local/lib/python3.10/site-packages/nose/case.py
you have to change two things, first
change import collections to import collections.abc and then change collections.Callable to collections.abc.Callable wherever you see the statement.

To run nosetests along with pinocchio and coverage
nosetests --with-spec --spec-color --with-coverage

The test cases highlighted in red are the ones that failed and the one highlighted in green has passed. We can also see that the code coverage for the file is 100% which is perfect. We can see that the exceptions were not raised. So let's update our code.

def rect(length,breadth):
    if type(length) not in [int,float] or type(breadth) not in [int,float]:
        raise TypeError("Length or Breadth must be int or float")
    return length*breadth

We have added a statement to raise TypeError if the type of length or breadth is not integer or float. Let's try out our test cases.

Great! test_bad_types has passed but still, the test_bad_values is not raising an exception when it is getting a negative or zero value for length or breadth. Let's modify our code again.

def rect(length,breadth):
    if type(length) not in [int,float] or type(breadth) not in [int,float]:
        raise TypeError("Length or Breadth must be int or float")
    if length<=0 or breadth<=0: 
        raise ValueError("Lenght or Breadth cannot be zero or negative")
    return length*breadth

Now we have added a statement to raise ValueError when we receive negative or zero values for length or breadth. Let's try our test cases once more.

Congratulations! All the test cases have been passed, the happy paths and the sad paths have been tested, the code coverage is 100% and our rect function is now ready to be pushed in production.

Quick tip: The nosetests command is a long one and everytime you run it, you need to pass all the required flags to trigger pinocchio and coverage. So add a file setup.cfg which will contain the following:

[nosetests]
verbosity=2
with-spec=1
spec-color=1
with-coverage=1
cover-package=app

[coverage:report]
show_missing = True

I have also added show_missing = True parameter which will pinpoint the line numbers which are not tested. Now just run nosetests without any parameter or flags, it will fetch all the required configuration flags and parameters from setup.cfg and will provide the same result.

So we now have understood the idea of TDD. Write test cases first and let your unit test derive your code.

Thank you,
Happy Coding!