112 tests now, and 2 factory functions - online edit of handbook/troggle/trogtests.html

This commit is contained in:
Expo on server 2024-07-04 20:57:55 +01:00
parent de66169e84
commit 1382b1b34a

View File

@ -5,12 +5,13 @@
<title>Handbook Troggle - Automated Testing</title> <title>Handbook Troggle - Automated Testing</title>
<link rel="stylesheet" type="text/css" href="/css/main2.css" /> <link rel="stylesheet" type="text/css" href="/css/main2.css" />
</head> </head>
<body><style>body { background: #fff url(/images/style/bg-system.png) repeat-x 0 0 }</style> <body>
<style>body { background: #fff url(/images/style/bg-system.png) repeat-x 0 0 }</style>
<h2 id="tophead">CUCC Expedition Handbook</h2> <h2 id="tophead">CUCC Expedition Handbook</h2>
<h1>Handbook Troggle - Automated Testing</h1> <h1>Handbook Troggle - Automated Testing</h1>
<h2>Troggle Automated Testing</h2> <h2>Troggle Automated Testing</h2>
<p>We have a suite of more than 100 <a href="https://en.wikipedia.org/wiki/Smoke_testing_(software)">smoke tests</a>. <p>We have a suite of more than 110 <a href="https://en.wikipedia.org/wiki/Smoke_testing_(software)">smoke tests</a>.
<p>These are 'end to end' tests which very quickly show whether something is badly broken. The tests are for two purposes only: <p>These are 'end to end' tests which very quickly show whether something is badly broken. The tests are for two purposes only:
<ul> <ul>
@ -66,7 +67,7 @@ No tests are run with the real expo database.
<var>troggle/core/fixtures/ </var> <var>troggle/core/fixtures/ </var>
which are JSON files containing dummy data which is read in before a few of the tests. which are JSON files containing dummy data which is read in before a few of the tests.
<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>. <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 a couple of these <var>create_user()</var> and <var>create_person()</var> in <var>core/TESTS/test_parsers.py</var> which we use to create 2 users ('expo' and 'expoadmin') and 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> <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 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.
@ -82,6 +83,5 @@ and look for types of url which do not appear in the test suite checks.
Go on to: <a href="trogarch.html">Troggle architecture</a><br /> Go on to: <a href="trogarch.html">Troggle architecture</a><br />
Return to: <a href="trogintro.html">Troggle intro</a><br /> Return to: <a href="trogintro.html">Troggle intro</a><br />
Troggle index: Troggle index:
<a href="trogindex.html">Index of all troggle documents</a><br /><hr /> <a href="trogindex.html">Index of all troggle documents</a><br /><hr /></body>
</body>
</html> </html>