python django: python django Automated testing part 2

Friday, June 15, 2018

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