Automated tests are usually used for testing functional requirements of your product code. But they can also be used to enforce other policies and coding practices as well.
If writing a web application it’s likely you already have a rule like “all automated tests must pass before any new version of the web application can be deployed to customers on the production environment”. In that case any new policies you want to enforce regularly can be added to your standard automated test suite and they will necessarily have to be satisfied on every deployment!
Here are some example of special policies I’ve enforced from the automated test suite of a large web application I work on (which uses Django, Python+mypy, and JavaScript+TypeScript as core technologies):
test_ that_ tests_ do_ not_ send_ real_ emails
test_ all_ django_ add_ and_ edit_ admin_ pages_ render
7 👈 especially useful and powerfultest_ every_ block_ type_ satisfies_ all_ block_ standards
8
test_ c_ blocks_ for_ python_ blocks_ must_ use_ consistent_ indent_ width
test_ every_ field_ id_ must_ use_ underscore_ case
test_ every_ block_ type_ whose_ codegen_ always_ references_ x_ library_ must_ import_ x_ library
test_ max_ redirect_ count_ is_ 5
9Hopefully these examples give you some ideas of some special policies you might enforce in your own automated test suite. Happy coding!
TechSmart’s backend Python and Django code is typechecked using the mypy type checker.↩
TechSmart’s frontend JavaScript code is typechecked using the TypeScript compiler, tsc
.↩
In this context a “fragile test suite” corresponds to a subclass of Django’s StaticLiveServerTestCase
or TestCase
whose setUpClass
method fails to use a try-finally
to invoke super().tearDownClass()
explicitly if something goes wrong partway through the test suite setup. This fragile-detection metatest walks through all test suite classes and uses Python’s inspect.getsourcelines
to read the source code of all test classes to look for the absense of the proper kind of try-finally.↩
It is important for any directory containing Python source files (*.py
) to contain an __init__.py
file so that the directory is marked properly as a Python package and is recognized correctly by Python typecheckers like mypy.↩
The Django Debug Toolbar is an amazingly useful tool to profile the database queries that your Django-rendered page is making.↩
TechSmart’s frontend JavaScript code is concatentated and minified using the excellent Django Compressor app. At some point we may migrate instead to using Snowpack, a lightweight module bundler.↩
The “all Django Add and Edit pages must render” metatest automatically discovers all Django models and related pages that exist in Django’s admin site. Then it tries to navigate to each such admin page and ensures that it renders completely. This metatest has caught cases where some of our more complex custom admin pages broke due to a code change elsewhere.↩
The “blocks” referred to here are the lego-like blocks which snap together to form programs in the visual Skylark language.↩
The Python IDE in the TechSmart Platform contains an API-compatible reimplementation of the popular Requests HTTP client library so that students can write programs that access the internet, in a controlled fashion.↩