From 5233b0e79760b06696d14afcdbb3aebbee72c716 Mon Sep 17 00:00:00 2001 From: Philip Sargent <philip.sargent@gmail.com> Date: Sun, 26 Mar 2023 20:47:52 +0100 Subject: [PATCH] udated tests documn --- handbook/troggle/trogtests.html | 14 +++++++++----- 1 file changed, 9 insertions(+), 5 deletions(-) diff --git a/handbook/troggle/trogtests.html b/handbook/troggle/trogtests.html index cb4e519c4..b638cebbb 100644 --- a/handbook/troggle/trogtests.html +++ b/handbook/troggle/trogtests.html @@ -10,10 +10,15 @@ <h1>Handbook Troggle - Automated Testing</h1> <h2>Troggle Automated Testing</h2> -<p>We have a suite of more than 90 <a href="https://en.wikipedia.org/wiki/Smoke_testing_(software)">smoke tests</a> +<p>We have a suite of more than 100 <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$ python3 manage.py test --parallel auto -v 1</code></pre> +or, if someone has made a mistake and the tests interfere with each other: <pre><code> troggle$ python manage.py test -v 1</code></pre> +<p>Running the tests in parallel works on the server too (without the 'auto' keyword on Django 3.2 though). + + <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 @@ -49,15 +54,14 @@ No tests are run with the real expo database. <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.) +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. +<p>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. We have one of these <var>make_person()</var> in <var>core/TESTS/test_parsers.py</var> which we use to create 4 people, which are then used when testing the import parser for a fragment of an invented logbook in <var>test_logbook_parse()</var>. <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 have got only one test which checks that the <a href="trogimport.html">input parsers</a> work. We only have a test for <var>parsers/logbooks</var>. +<p>We have got only one test which checks that the <a href="trogimport.html">input parsers</a> work. We need tests for parsing survex files and for reading the JSON files for the wallets. We could laos do with a directory browser/parser test for the survey scan files and for the HTML fragment file which make up the cave descriptions. <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