python django Automatic Testing part 4

Know the testing output

The testing output of django here we will see that when we run our tests we will see number of test messages as the test runner prepares itself .Test runner is a component which orchestrates the execution of tests and provides the outcome to the user it may use a graphical interface a textual interface or return a special value to indicate the results of executing the tests
                    If you wish you can control the level of detail of these messages with the verbosity option on the command line like you can run tests with more detail (higher verbosity) by passing in the -v flag some of the other options are
-b,--buffer:
the standard output and standard error streams are buffered during the test run output during a passing test is discarded output is echoed normally on test fail or error and is added to the failure messages
-c,--catch:
     control c during the test run waits for the current test to end and then reports all the results so far A second control-c raises the normal KeyboardInterrupt exception
-f --failfast:
 stop the test run on the first error or failure
--locals:
   show local variables in tracebacks
and you can get all the command line options put -h as  

python -m unittest -h

here is an example of using -v

python -m unittest -v test_module

likewise we can use the options and after running the tests here

Creating test database...
Creating table myapp_database
Creating table myapp_mineral

This here tells you that the test runner is creating a test database as described in the previous posts once the database has been created Django will run your tests if every thing goes well we will see something like this as for example

----------------------------------------------------------------------

Ran 22 tests in 0.221s

OK

otherwise we will get error like this

======================================================================
FAIL: test_was_published_recently_with_future_poll (polls.tests.PollMethodTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/dev/mysite/polls/tests.py", line 16, in test_was_published_recently_with_future_poll
    self.assertIs(future_poll.was_published_recently(), False)
AssertionError: True is not False

----------------------------------------------------------------------
Ran 1 test in 0.003s

FAILED (failures=1)

To learn more about python unittest you can go to this link one thing to note here the return code for the test runner script is 1 for any number of failed and erroneous test if all tests pass the return code is 0 this feature is useful if you're using the test runner script in a shell script and need to test for success or failure at that level


 Thats for this post guys more on testing will be on next post please comment share and follow this blog

python django Automated testing part 3(please read my previous post ))

Finding data form production database when running tests
       if the code attempts to access the database when its modules are compiled this will occur before the test database is set up with potentially unexpected results For example if we have a database query in the module level code and a real database exists . then the production data could pollute the tests it is a bad idea to have such import time database queries in your code
so we should have to rewrite the code so that it doesn't do this. This also applies to customized implementation of ready()

Order of Test execution

Django test runner reorders tests as

• All the TestCase subclasses are run first
• Then all other Django-based tests (test case based on SimpleTestCase,including TransactionTestCase) are run with no particular ordering guaranteed nor enforced among them
• then any other unittest.TestCase test (including doctests) which may alter the database without restoring it to its orginal state are run

Note:
     The new ordering of tests may reveal unexpected dependencies on test case ordering this is the case with doctests that relied on state left in the database by a given TransactionTestCase test they must be updated to be able to run independently

To ensure your tests are indepndent from each other you may reverse the execution order inside groups using the test --reverse option

Make initial data loaded Available(Rollback emulation)
        It is only be available in TestCase tests and not in TransactionTestCase tests and this also true for tests which rely on TransactionTestCase such as LiveServerTestCase and StaticLiveServerTestCase
and available to only on backends where transactions are supported the most important exception being MyISAM
By setting the serialized_rollback option to True in the body of the TestCase or TransactionTestCase django can reload that data for you on a per testcase basis but it will slow down that test suite by approximately 3x
We can exclude some apps from this process and speed up test runs slightly to this add those apps to TEST_NON_SERIALIZED_APPS to prevent serialized data from being loaded twice setting serialized_rollback = True disables the post_migrate signal when flushing the test database

Some Test conditions
   The value of  the DEBUG = False is set on all django tests run this is to ensure that the observed output of our code matches what will be seen in a production setting
Caches are not cleared after each test and running "manage.py test myapp" can insert data from test into the cache of a live system if you run your tests in production because unlike databases a separate "test cache" is not used This behavior may change in the future
Speeding up the tests
    By running tests in parallel as long as your tests are properly isolated it will run in parallel to gain speed up on multicore hardware. one thing to note here when test parallelization is enabled and a test fails django may be unable to display the exception traceback This can make debugging difficult if you encounter this problem run the affected test without parallelization to see the traceback of the failure
Password hashing
    default password hasher is slow by design if you are authenticating many users in your tests you may want to use a custom settings file and set the PASSWORD_HASHER setting to a faster hashing algorithm

PASSWORD_HASHERS = [
'django.contrib.auth.hashers.MD5PasswordHasher',
]

Also include PASSWORD_HASHERS any hashing algorithm used in fixtures If any

 Thats all for this post guys hope you understand and like this post to get latest updates on this lesson follow by email and don't forget to follow and share if you have any suggestions or doubts please include it in the comment section so that i can improve my next post

python django Automated testing part 2

Running Test

we have learned about tests in the previous lesson now here we can see how to run the test to run the test write this code in the commandline as

$/. manage.py test

The test are discovered with using the built in test discovery which by default in python which will discover any file named test.py under the current working directory we can also specify the specific that is required in by supplying any number of test labels to ./manage.py test which are a full python dotted path to a package, module, Test case subclasses or test methods like in here

# to run all the tests in the vehicles.tests module
$ ./manage.py test vehicles.tests

#to run all the tests in the vehicle package
$./manage.py test vehicles

# to run one test case
$./ manage.py test vehicles.tests.VehicleTestCase

#to run just one test method
$ ./manage.py test vehicles.tests.VehicleTestCase.test_vehicle_can_fly

#to provide a path to a directory to discover tests below that directory
$ ./manage.py test vehicles/

we can also specify a custom file name pattern using the -p (or --pattern) option if your test files are named differently from the test*.py pattern

$ ./manage.py test --pattern = *tests_*.py*

Test which requires databases ( namely model test) will not use the real production database they use a separate blank database are created for tests regardless of the tests pass or fail the test database are destroyed when all the tests have been executed you can prevent the database being destroyed using the test --keepdb option this will preserve the test database between runs if the database does not exist it will be created first any migrations will also be applied in order to keep it up to date
to complete the test currently running and exit gracefully we need to press Ctrl-c it will wait for the currently running test to complete and then exit gracefully and it will output the details of any test failures report on how many tests were run and how many errors and failures were encountered and destroy any test database as usual if you forget to pass --failfast option then you can use this Ctrl-c and if you don't want to wait for the current test to finish press Ctrl-c once more and the test run will halt immediately but not gracefully no details of the tests run before the interruption will be reported and any test databases created by the run will not be destroyed
we can use this flag --Wall which tell python to display deprecation warnings django like many other python libraries uses these warnings to flag when features are going away  it also might flag the codes which are not strictly wrong but could benefit from a better implementation

More on test database

The test database names are created by prepending test_ to the value of each NAME in DATABASES when using SQLite the tests will use an inmemory database by default the database will be created in memory ,bypassing the filesystem entirely The TEST dictionary in DATABASES offers a number of settings to configure your test database and if you want to use a different database name specify NAME in the TEST dictionary for any given database in DATABASES

On PostgreSQL USER will also need read access to the built in postgres database
and also test runner will use all of the same database settings which we have in our settings file:ENGINE, USER, HOST ,etc we need to make sure that the given user account has sufficient privileges to create a new database on the system due to the reason that the test database is created by the user specified by USER

For fine grained control over the character encoding of the test database use the CHARSET TEST option and COLLATION option for MySQL to control the particular collation used by the test database
And there is a facility using SQLite 3.7.13+ which is shared cache which is enabled so you can write tests with the ability to share the database between threads

Thats all for this post guys more will be included in the next post hope you like the post waiting for your suggestions to improve my posts so please comment , share and to get latest updates on this lessons follow by email and follow me 

python django Automated Testing

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

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'")

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

More on how to run the tests and more will be included in the next post hope you like the post to get latest updates please follow by email and dont forget to share ,follow and comment below your doubts and suggestions