expoweb/handbook/troggle/trogtests.html
2021-12-01 20:24:34 +00:00

73 lines
3.9 KiB
HTML

<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<title>Handbook Troggle - Automated Testing</title>
<link rel="stylesheet" type="text/css" href="../../css/main2.css" />
</head>
<body><style>body { background: #fff url(/images/style/bg-system.png) repeat-x 0 0 }</style>
<h2 id="tophead">CUCC Expedition Handbook</h2>
<h1>Handbook Troggle - Automated Testing</h1>
<h2>Troggle Automated Testing</h2>
<p>We have a suite of more than 70 <a href="https://en.wikipedia.org/wiki/Smoke_testing_(software)">smoke tests</a>
which are run manually by troggle programmers like this:
<pre><code> troggle$ python manage.py test -v 1</code></pre>
<p>These are 'end to end' tests which very quickly show whether something is badly broken. The tests are for two purposes only:
<ul>
<li>To check whether anything has broken when we try a new version of python, Django or a Django plugin
<li>To check that the troggle system has been installed correctly on a new machine
</ul>
<p>This is surprisingly effective. Django produces excellently detailed tracebacks when an fault happens,
which allow us to home in on the precise part of the code which has been broken by a version upgrade.
<p>We do also have a handful of unit tests which just poke data into the database and check that it can be read out again.
<p>
The test code is all in <a href="http://expo.survex.com/repositories/troggle/.git/tree/core/TESTS/"><var>troggle/core/TESTS/</var></a>.
<h4>Example test</h4>
<p>The test 'test_page_expofile' checks that a particular PDF is being served correctly by the web server
and that the resulting page is the correct length of 2,299,270 bytes:
<pre><code>
def test_page_expofile(self):
# Flat file tests.
response = self.client.get('/expofiles/documents/surveying/tunnel-loefflerCP35-only.pdf')
self.assertEqual(response.status_code, 200)
self.assertEqual(len(response.content), 2299270)
</code></pre>
<h3>Django test system</h3>
<p>This test suite uses the <a href="https://docs.djangoproject.com/en/3.2/topics/testing/">the
django test system</a>. One of the things this does
is to ensure that all the settings are imported correctly and makes it easy to specify a test as an input URL and expected
HTML output using a Django object <a href="https://docs.djangoproject.com/en/3.2/topics/testing/tools/">text client</a>.
It sets up a very fast in-memory sqlite database purely for tests.
No tests are run with the real expo database.
<h3>Troggle tests</h3>
<p>The tests can be run at a more verbose level by setting the <var>-v 3</var> flag.
<p>As yet we have no test database set up, so the in-memory database starts entirely empty. However we have 'fixtures' in
<var>troggle/core/fixtures/ </var>
which are JSON files containing dummy data which is read in before a few of the tests.
<h4>Automated testing on the server</h4>
<p>Something is stopping the test suite running on the server. We haven't fixed this yet.
<h4>How you can help</h4>
<p>We could do with a lot more unit tests which test small, specific things. If we have a lot of these it will make future re-engineering of troggle easier, as we can more confidently tackle big re-writes and still be sure that nothing is broken.
<p>We haven't got any tests which check that the <a href="trogimport.html">input parsers</a> work. None.
<p>Have a look at Wikpedia's <a href="https://en.wikipedia.org/wiki/Software_testing">review of types of software testing</a> for ideas.
<p>If you want to write some tests and are having trouble finding something which is untested, have a look at the list of
url paths in the routing system in <var>troggle/urls.py</var>
and look for types of url which do not appear in the test suite checks.
<hr />
Go on to: <a href="trogarch.html">Troggle architecture</a><br />
Return to: <a href="trogintro.html">Troggle intro</a><br />
Troggle index:
<a href="trogindex.html">Index of all troggle documents</a><br /><hr />
</body>
</html>