mirror of
https://expo.survex.com/repositories/expoweb/.git/
synced 2024-11-22 15:21:55 +00:00
73 lines
4.1 KiB
HTML
73 lines
4.1 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 85 <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. (Though current wisdom is that <a href="https://lukeplant.me.uk/blog/posts/test-factory-functions-in-django/">factory methods in the test suite</a> are a superior way of managing tests for very long-term projects like ours.)
|
|
|
|
<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>
|