Automated Testing
The automated testing are simple routines that checks the operation of your code . There are some tests which tests the small part of the code and others are which tests the overall operation of the program automated tests are tests which are done by the system for us like we create a set of tests and then we make changes to our app and test if the code works as if we it were originally intended to work without performing time consuming manual testing
Benefits of Testing
- Test will save Time:If we change any of the components of the code could cause unexpected application behavior checking that it still works means running the test through your code functionality with twenty different variations of your test data just to make sure its working properly this is not a good use of time we can do this test in seconds with automated testing like writing the automated test is more beneficial than testing your application manually
- Test prevent the problem: they can prevent the coming problems from identifying them early before you could fall in any problems
- Test make the code more attractive: if you have made an amazing software then also most developers will refuse to take your software because it lacks tests they won't trust it jacob koplan moss one of the original developers of django says that code without test is broken by design the other developers want see test in your software to take it seriously
- Test helps teams work together: The tests helps in software which are made by teams test guarantees that the colleagues don't inadvertently break your code and you don't break their code without knowing
The different Testing strategies
There are many ways to approach on writing test one of the discipline is the test driven development in which that relies on the repetition of a very short development cycle requirements are turned in to very specific test cases then the software is improved to pass the new tests only some programmers write their tests before their code test driven development simply formalizes the problem in a python test case it will be difficult to figure out where to get started with writing test if there are thousands of line of python code choosing something to test might not be easy its beneficial write the first test before you make a change either when you add a new feature or fix bugs
Start to write our first Test
The django unit test uses the python standard library module unittest
this module defines test using a class based approach first in our code we make a subclass of TestCase from django.test which is a subclass of unittest.TestCase that runs each test inside a transaction to provide isolation
this module defines test using a class based approach first in our code we make a subclass of TestCase from django.test which is a subclass of unittest.TestCase that runs each test inside a transaction to provide isolation
from django.test import TestCase
from myapp.models import Animal
class AnimalTestCase (TestCase):
def setup(self):
Animal.objects.create(name= "lion" ,color = "brown")
Animal.object .create(name = "tiger", color = "red")
def animal_has_color(self):
"""Animals that have color are identified"""
Lion = Animal.objects.get(name = "lion")
Tiger = Animal.objects.get(name = "tiger")
self.assertEqual(lion.color(),"the lion has color 'brown'")
self.assertEqual(tiger.color(),"the tiger has color 'red'")
from myapp.models import Animal
class AnimalTestCase (TestCase):
def setup(self):
Animal.objects.create(name= "lion" ,color = "brown")
Animal.object .create(name = "tiger", color = "red")
def animal_has_color(self):
"""Animals that have color are identified"""
Lion = Animal.objects.get(name = "lion")
Tiger = Animal.objects.get(name = "tiger")
self.assertEqual(lion.color(),"the lion has color 'brown'")
self.assertEqual(tiger.color(),"the tiger has color 'red'")
In here the test case when we run it the default behavior of the test utility is to find all the test cases that is subclasses of unittest.TestCase in any file whose name begins with test automatically build a test suite out of those test cases and run the test suit
As explained in my previous chapters by default the test.py file will be created in the new applicatiion of "myproj" folder but this will not be enough as your test suite grows at that time you will need to restructure it into a tests package so you can split your tests into different submodels such as test_models.py,test_views.py,test_forms.py etc you can pick whatever organizational scheme you like and one important point to note here is if your tests rely on database access such as creating or querying models be sure to create the test classes as subclasses of django.test.TestCase rather than unittest.TestCase because using unittest.TestCase avoids the cost of running each test in a transaction and flushing the database but if your tests interact with the database their behavior will vary based on the order that the test runner executes then this can lead to unit tests that pass when run in isolation but fails when run in a suite
As explained in my previous chapters by default the test.py file will be created in the new applicatiion of "myproj" folder but this will not be enough as your test suite grows at that time you will need to restructure it into a tests package so you can split your tests into different submodels such as test_models.py,test_views.py,test_forms.py etc you can pick whatever organizational scheme you like and one important point to note here is if your tests rely on database access such as creating or querying models be sure to create the test classes as subclasses of django.test.TestCase rather than unittest.TestCase because using unittest.TestCase avoids the cost of running each test in a transaction and flushing the database but if your tests interact with the database their behavior will vary based on the order that the test runner executes then this can lead to unit tests that pass when run in isolation but fails when run in a suite
No comments:
Post a Comment