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