Gain insights into test-driven development in Django, explore the differences between test methodologies, and learn to build robust applications through unit testing and Red-Green Refactor methodology.

django-docker.tar.gz

ALLOWED_HOSTS

steps involved in test-driven development

As Django co-founder Jacob Kaplan-Moss says, “code without tests is broken as designed.” That’s why it’s essential to develop your applications with tests and success conditions in mind.

This course is an introduction to test-driven development and a practical guide on applying these principles to Django development. You’ll start with the purpose of automated testing, including the differences between test-driven development and development-driven testing. You’ll then be introduced to Django, a Python framework for building web applications. You’ll design and write a series of unit tests before building a complete web application using Django—a web application that will pass all the tests you designed, to ensure a robust, low-risk experience.

By the end of this course, you’ll be familiar with test-driven development, Red-Green Refactor methodology, and deploying quality applications using Django.

Build Robust Applications with Test-driven Development in Django

The TDD process consists of the following five steps:

1. Write the test.
2. Run the test.
3. Write the actual code.
4. Make all tests pass.
5. Refactor and improve the code.

After we install and configure our Django project, we write the test. We need to do this before we start adding any new feature or code the application However, before we can write the test, we must understand the application as a whole. This includes the requirements, project specifications, and what the feature we’re adding is intended to do. We need this so that the unit test we write captures the needed feature.










This process is effective. Since we have to write the test first, it forces us to think about the requirements before we start coding the application.

This will save you time in future, as the project was well thought off, and you understand what the feature is meant to do.

However, this test is intended to fail initially because it will only pass when the feature specification is met. This occurs only in the later period of the TDD process when we write the actual code.

# How does it work?

As developers, we must be proactive to think about the feature specification we want to implement. For demonstration purposes, let’s say we want to implement a user profile functionality. It could be a feature to show a particular user’s profile. Therefore, a sample test could be used to check if the HTML page we use returns what is expected:

```py
from django.test import SimpleTestCase
from django.urls import reverse

class TestUserProfile(SimpleTestCase):
    def test_user_profile_contains_correct_html(self):
        response = self.client.get(reverse('user'))
        self.assertContains(response, 'Profile')
```

In this test, we check if the word `Profile` is present in the HTML file when calling the route stated in the URL name of `user.` We use the `reverse` method to do this. So, if we accidentally change the text in the HTML and omit the word `Profile,` the test fails, and we’re adequately prompted.

# Test the template
We can also test that the actual template to be used was, in fact, used when the view function is called:

```py
from django.test import SimpleTestCase
from django.urls import reverse

class TestUserProfile(SimpleTestCase):
    def test_user_profile_template(self):
        response = self.client.get(reverse('user'))
        self.assertTemplateUsed(response, 'user.html')
```

Here, we are testing if the template used to get the user profile is `user.html`. Therefore, if it is not, it will produce an error.

# Testing the URL

Here, we test if the template used to get the user profile is `user.html.` If not, it produces an error.

```py
from django.test import SimpleTestCase
from django.urls import reverse

class TestUserProfile(SimpleTestCase):
    def test_user_profile_code(self):
        response = self.client.get(reverse('user'))
        self.assertEqual(response.status_code, 200)
```

# Test the models

In Django, we use models to store the required table, field, and data type in our database. We can test our model in the following way:

```py
from django.test import TestCase

from .models import Profile

class TestUserProfileModel(TestCase):
    def test_create_user_profile(self):
        self.profile = Profile.objects.create(
            first_name = 'Samuel',       
            last_name = 'Torimiro',
        )

        self.assertEqual(f'{self.profile.first_name}', 'Samuel')
        self.assertEqual(f'{self.profile.last_name}', 'Torimiro')
```

Here, we create a sample profile to test. The function also tests if the contents are correct.

> __Note:__ All the tests written above are very descriptive. This is important to let other developers understand what each test does.

The examples shown above are just the beginning of what’s possible, since we can test even more things. However, not every functionality in Django should be tested because any default functionality that comes preinstalled with Django has its own test. This includes any third-party packages we install. Therefore, testing something like the Django admin panel isn’t required.

Learn to write tests in test-driven development.

Introduction

Steps Involved in Test-driven Development

E-library Application: Part One

E-library Application: Part Two

E-library Application: Part Three

What's Next?

Conclusion

Writing the Test