hello and welcome to my blog, in this post I will discuss how to writing unitest (functional test) with python,
What is Functional Testing
Tests that use Selenium let us drive a real web browser, so they really let us see how the application functions from the user’s point of view. That’s why they’re called functional tests.
before implementing functional testing on Django project using python we need, to set up several things like
- Create Virtual Environment
- Installing the required package
- Creating Django project
- Set-Up unittest
Create Virtual Environment
To create a virtual environment, using this command
python -m venv django-tdd
Installing required Package
to writing unittest, I need to Install some python package, the package is
install with pip
pip install selenium webdriver-manager django
Creating Django Project
to create a Django project using this command
django-admin startproject config
we create Django project named
then the project structure will be like this
. ├── config │ ├── asgi.py │ ├── __init__.py │ ├── __pycache__ │ │ ├── __init__.cpython-39.pyc │ │ ├── settings.cpython-39.pyc │ │ ├── urls.cpython-39.pyc │ │ └── wsgi.cpython-39.pyc │ ├── settings.py │ ├── urls.py │ └── wsgi.py ├── db.sqlite3 ├── functional_tests.py ├── manage.py ├── README.md ├── requirements.txt └── temp └── driver ├── drivers │ └── chromedriver │ └── linux64 │ └── 92.0.4515.107 │ ├── chromedriver │ └── driver.zip └── drivers.json
Writing Functional Testing
create a file named
functional_test.py then write code like this
import os import unittest from selenium import webdriver from webdriver_manager.chrome import ChromeDriverManager class NewVisitorTest(unittest.TestCase): def setUp(self): # creating temporary directory try: os.mkdir('temp') except FileExistsError: pass # creating directory to Append Driver try: os.mkdir('temp/driver') except FileExistsError: pass # initialize the browser self.driver = webdriver.Chrome(ChromeDriverManager(path='temp/driver').install()) def tearDown(self): self.driver.quit() # the unittest def test_start_web(self): url: str = 'http://127.0.0.1:8000/' self.driver.get(url=url) self.assertIn('Todo', self.driver.title) self.fail('test Finished') if __name__ == '__main__': unittest.main()
in this case, we write the test to check whether the website is running or not
setUp() the method we initialize the driver to remote our chrome browser
def setUp(self): # creating temporary directory try: os.mkdir('temp') except FileExistsError: pass # creating directory to Append Driver try: os.mkdir('temp/driver') except FileExistsError: pass # initialize the browser self.driver = webdriver.Chrome(ChromeDriverManager(path='temp/driver').install())
tearDown() is to set up when the test case is complete
def tearDown(self): self.driver.quit()
test_start_web() is a method to test our web
def test_start_web(self): url: str = 'http://127.0.0.1:8000/' self.driver.get(url=url) self.assertIn('Todo', self.driver.title) self.fail('test Finished')
and then you run this case you got a failed response because the title is not the same with
====================================================================== FAIL: test_start_web (__main__.NewVisitorTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "/Devs/JOBS/Django Project/django-tdd/fuctional_tests.py", line 33, in test_start_web self.assertIn('Todo', self.driver.title) AssertionError: 'Todo' not found in 'The install worked successfully! Congratulations!
Terminology: Functional Test == Acceptance Test == End-to-End Test
What I call functional tests, some people prefer to call acceptance tests or end-to-end tests. The main point is that these kinds of tests look at how the whole application functions, from the outside. Another term is black box test because the test doesn’t know anything about the internals of the system under test.
FTs should have a human-readable story that we can follow. We make it explicit using comments that accompany the test code. When creating a new FT, we can write the comments first, to capture the key points of the User Story. Being human-readable, you could even share them with nonprogrammers, as a way of discussing the requirements and features of your app.
TDD and agile software development methodologies often go together, and one of the things we often talk about is the minimum viable app; what is the simplest thing we can build that is still useful? Let’s start by building that so that we can test the water as quickly as possible.
This means that an FT can be a sort of specification for your application. It tends to track what you might call a User Story, and follows how the user might work with a particular feature and how the app should respond to them.