-
Notifications
You must be signed in to change notification settings - Fork 0
/
UnitTestGoodPractice.html
344 lines (301 loc) · 17.7 KB
/
UnitTestGoodPractice.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
<!DOCTYPE html>
<html lang="en" data-content_root="./">
<head>
<meta charset="utf-8" />
<meta name="viewport" content="width=device-width, initial-scale=1.0" /><meta name="viewport" content="width=device-width, initial-scale=1" />
<title>Unit Test Good Practice</title>
<link rel="stylesheet" type="text/css" href="_static/pygments.css?v=fa44fd50" />
<link rel="stylesheet" type="text/css" href="_static/bootstrap-sphinx.css?v=fadd4351" />
<link rel="stylesheet" type="text/css" href="_static/custom.css?v=77160d70" />
<script src="_static/documentation_options.js?v=30d551ce"></script>
<script src="_static/doctools.js?v=9a2dae69"></script>
<script src="_static/sphinx_highlight.js?v=dc90522c"></script>
<link rel="index" title="Index" href="genindex.html" />
<link rel="search" title="Search" href="search.html" />
<link rel="next" title="Reviewing a Pull Request" href="ReviewingAPullRequest.html" />
<link rel="prev" title="Debugging Unit Tests" href="DebuggingUnitTests.html" />
<script>
(function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r;i[r]=i[r]||function(){
(i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o),
m=s.getElementsByTagName(o)[0];a.async=1;a.src=g;m.parentNode.insertBefore(a,m)
})(window,document,'script','//www.google-analytics.com/analytics.js','ga');
ga('create', 'UA-59110517-1', 'auto');
ga('send', 'pageview');
</script>
</head><body>
<div id="navbar" class="navbar navbar-default ">
<div class="container">
<div class="navbar-header">
<!-- .btn-navbar is used as the toggle for collapsed navbar content -->
<button type="button" class="navbar-toggle" data-toggle="collapse" data-target=".nav-collapse">
<span class="icon-bar"></span>
<span class="icon-bar"></span>
<span class="icon-bar"></span>
</button>
<a class="navbar-brand" href="http://www.mantidproject.org">
</a>
<span class="navbar-text navbar-version pull-left"><b>master</b></span>
</div>
<div class="collapse navbar-collapse nav-collapse">
<ul class="nav navbar-nav">
<li class="divider-vertical"></li>
<li><a href="index.html">Home</a></li>
<li><a href="https://download.mantidproject.org">Download</a></li>
<li><a href="https://docs.mantidproject.org">User Documentation</a></li>
<li><a href="http://www.mantidproject.org/contact">Contact Us</a></li>
</ul>
<form class="navbar-form navbar-right" action="search.html" method="get">
<div class="form-group">
<input type="text" name="q" class="form-control" placeholder="Search" />
</div>
<input type="hidden" name="check_keywords" value="yes" />
<input type="hidden" name="area" value="default" />
</form>
</div>
</div>
<p>
<div class="related" role="navigation" aria-label="related navigation">
<h3>Navigation</h3>
<ul>
<li class="nav-item nav-item-0"><a href="index.html">Documentation</a> »</li>
<li class="nav-item nav-item-this"><a href="">Unit Test Good Practice</a></li>
</ul>
</div> </p>
</div>
<div class="container">
<div class="row">
<div class="body col-md-12 content" role="main">
<section id="unit-test-good-practice">
<span id="unittestgoodpractice"></span><h1>Unit Test Good Practice<a class="headerlink" href="#unit-test-good-practice" title="Link to this heading">¶</a></h1>
<nav class="contents local" id="contents">
<ul class="simple">
<li><p><a class="reference internal" href="#general-guidance" id="id2">General Guidance</a></p>
<ul>
<li><p><a class="reference internal" href="#what-to-test" id="id3">What to test</a></p></li>
<li><p><a class="reference internal" href="#how-to-test-private-or-protected-members-of-a-class" id="id4">How to test private or protected members of a class</a></p>
<ul>
<li><p><a class="reference internal" href="#protected" id="id5">Protected</a></p></li>
<li><p><a class="reference internal" href="#private" id="id6">Private</a></p></li>
</ul>
</li>
<li><p><a class="reference internal" href="#good-practices-for-writing-tests" id="id7">Good practices for writing tests</a></p>
<ul>
<li><p><a class="reference internal" href="#other-more-general-points" id="id8">Other More General Points</a></p></li>
</ul>
</li>
</ul>
</li>
<li><p><a class="reference internal" href="#mantid-specific-guidelines" id="id9">Mantid-specific Guidelines</a></p>
<ul>
<li><p><a class="reference internal" href="#using-files-in-unit-tests" id="id10">Using files in Unit tests</a></p></li>
</ul>
</li>
<li><p><a class="reference internal" href="#mocking" id="id11">Mocking</a></p></li>
</ul>
</nav>
<section id="general-guidance">
<h2><a class="toc-backref" href="#id2" role="doc-backlink">General Guidance</a><a class="headerlink" href="#general-guidance" title="Link to this heading">¶</a></h2>
<section id="what-to-test">
<h3><a class="toc-backref" href="#id3" role="doc-backlink">What to test</a><a class="headerlink" href="#what-to-test" title="Link to this heading">¶</a></h3>
<p>Simply put you should test.</p>
<ul class="simple">
<li><p>Every public member of a class.</p></li>
<li><p>That the class can be cast to any of the interfaces or base classes
it inherits from.</p></li>
<li><p>Any private or protected members.</p>
<ul>
<li><p>That aren’t directly covered by a public method test.</p></li>
<li><p>That do any significant processing.</p></li>
</ul>
</li>
</ul>
<p>For each method you are testing you should include tests for the
following:</p>
<ul class="simple">
<li><p>To confirm that the methods meet the requirements associated with
them. Thus the test should verify that the function does what it is
supposed to do.</p></li>
<li><p>To confirm the expected behaviour for boundary and special values.</p></li>
<li><p>To confirm that exceptions are thrown when expected.</p></li>
</ul>
</section>
<section id="how-to-test-private-or-protected-members-of-a-class">
<h3><a class="toc-backref" href="#id4" role="doc-backlink">How to test private or protected members of a class</a><a class="headerlink" href="#how-to-test-private-or-protected-members-of-a-class" title="Link to this heading">¶</a></h3>
<p>Testing the internals of a class can be considered harmful as it exposes
the internals of the class, which can arguably be freely changed (so
long as it does not affect the function of the public interface).
However there are cases where the internals of a class need unit tests
either due to complexity or tracking down specific bugs.</p>
<p>In the circumstance where the implementation within the private/protected
methods of a class is sufficiently complex, such to require dedicated unit
tests, this code should be moved into a separate class(es).</p>
<section id="protected">
<h4><a class="toc-backref" href="#id5" role="doc-backlink">Protected</a><a class="headerlink" href="#protected" title="Link to this heading">¶</a></h4>
<p>Within the test library you can add a new testable class that inherits
from the class you need to test. This class can simply expose any
protected methods as testable public methods.</p>
</section>
<section id="private">
<h4><a class="toc-backref" href="#id6" role="doc-backlink">Private</a><a class="headerlink" href="#private" title="Link to this heading">¶</a></h4>
<p>There is no ideal way to test a private member of a class as they are
intentionally hidden from the class interface. There are two options to
consider in preference order:</p>
<ol class="arabic simple">
<li><p>Change the protection level to protected and follow the approach
above.</p></li>
<li><p>Declare the test class as a friend, which can access private members.</p></li>
</ol>
</section>
</section>
<section id="good-practices-for-writing-tests">
<h3><a class="toc-backref" href="#id7" role="doc-backlink">Good practices for writing tests</a><a class="headerlink" href="#good-practices-for-writing-tests" title="Link to this heading">¶</a></h3>
<p>The following are good practices for writing your unit tests. Many of
them are standard good coding practices. You will notice that in several
situations they can clash with each other, in this case common sense
needs to be applied.</p>
<ul class="simple">
<li><p>Unit tests should test one method only. This allows you to easily
identify what failed if the test fails.</p></li>
<li><p>Unit tests should not be coupled together, therefore one unit test
<strong>CANNOT</strong> rely on another unit test having completed first.</p></li>
</ul>
<p>These two often clash, in which case it is often better to compromise on
the first, and in fact we have relaxed this rule for Mantid (see below).</p>
<ul class="simple">
<li><p>Units tests should use realistic data</p></li>
<li><p>Unit tests should use small and simple data sets.</p></li>
</ul>
<p>Again these can often conflict.</p>
<ul class="simple">
<li><p>Each test class should be named after the class it is testing (e.g.
tests for the <code class="docutils literal notranslate"><span class="pre">AlgorithmFactory</span></code> should go in a <code class="docutils literal notranslate"><span class="pre">AlgorithmFactoryTest</span></code>
class).</p></li>
<li><p>Each test within a test class should use a descriptive test name,
prefixed with test (tests for the <code class="docutils literal notranslate"><span class="pre">CreateAlgorithm</span></code> method would be
included in <code class="docutils literal notranslate"><span class="pre">testCreateAlgorithm</span></code>). If there are specific tests for
failure situations then these should be added to the end (e.g.
<code class="docutils literal notranslate"><span class="pre">testCreateAlgorithmNoAlgorithmException</span></code>). THE AIM IS THAT FROM THE
TEST METHOD NAME ALONE, YOU SHOULD BE ABLE TO IDENTIFY THE PROBLEM.</p></li>
</ul>
<section id="other-more-general-points">
<h4><a class="toc-backref" href="#id8" role="doc-backlink">Other More General Points</a><a class="headerlink" href="#other-more-general-points" title="Link to this heading">¶</a></h4>
<ul class="simple">
<li><p>Tests should be <strong>fast</strong>, ideally really fast - certainly not more
than a few seconds. Unit tests test functionality, performance tests
can be used to check stress and timings.</p></li>
<li><p>Untestable code is a code-smell, if you can’t get the code under test
it probably needs refactoring.</p></li>
<li><p>Weight your testing to be destructive rather than demonstrative.
Destructive tests have a higher efficacy for finding bugs.</p></li>
</ul>
</section>
</section>
</section>
<section id="mantid-specific-guidelines">
<h2><a class="toc-backref" href="#id9" role="doc-backlink">Mantid-specific Guidelines</a><a class="headerlink" href="#mantid-specific-guidelines" title="Link to this heading">¶</a></h2>
<ul>
<li><p>As noted above, you can assume that individual tests within a cxxtest
suite will be run in order.</p></li>
<li><p>There must be <strong>no relative paths</strong> (or, more obviously, absolute
ones) used in tests as with CMake the code can be build anywhere with
respect to the source tree. Make use of the datasearch.directories
property (which CMake configures to hold correct paths for a given
build).</p></li>
<li><p>Ideally, test suites should not have a constructor. If one is
required, the following boiler-plate code <strong>must</strong> be inserted in the
test class:</p>
<div class="highlight-c++ notranslate"><div class="highlight"><pre><span></span><span class="k">static</span><span class="w"> </span><span class="n">NameOfTest</span><span class="w"> </span><span class="o">*</span><span class="nf">createSuite</span><span class="p">()</span><span class="w"> </span><span class="p">{</span><span class="w"> </span><span class="k">return</span><span class="w"> </span><span class="k">new</span><span class="w"> </span><span class="n">NameOfTest</span><span class="p">();</span><span class="w"> </span><span class="p">}</span>
<span class="k">static</span><span class="w"> </span><span class="kt">void</span><span class="w"> </span><span class="nf">destroySuite</span><span class="p">(</span><span class="n">NameOfTest</span><span class="w"> </span><span class="o">*</span><span class="n">suite</span><span class="p">)</span><span class="w"> </span><span class="p">{</span><span class="w"> </span><span class="k">delete</span><span class="w"> </span><span class="n">suite</span><span class="p">;</span><span class="w"> </span><span class="p">}</span>
</pre></div>
</div>
<p>where <code class="docutils literal notranslate"><span class="pre">NameOfTest</span></code> is the name of the test class. Without this, the
class is turned into a static meaning that the constructor is run at
initialisation even if (via an argument) you are not going to run that
particular test suite. Also, this can cause problems if running tests in
parallel.</p>
</li>
<li><p>Be cautious in use of the <code class="docutils literal notranslate"><span class="pre">setUp()``and</span> <span class="pre">``tearDown()</span></code> methods. Be aware
that if you use these in your suite they will be run before/after
<strong>every single</strong> individual test. That’s fine if it’s the behaviour
you really need, but we have found that to be rare - use the
constructor or set things up within the test.</p></li>
<li><p>To avoid clashes, use unique names for workspaces that will go into
the [Analysis Data Service], perhaps by prepending the name of the
test suite. Even better, don’t put workspaces into the ADS in the
first place: for example, an InputWorkspace property can be set via
pointer instead of by name.</p></li>
<li><p>Clean up the ADS at (or before) the end of the test suite.</p></li>
</ul>
<section id="using-files-in-unit-tests">
<h3><a class="toc-backref" href="#id10" role="doc-backlink">Using files in Unit tests</a><a class="headerlink" href="#using-files-in-unit-tests" title="Link to this heading">¶</a></h3>
<p>Files for unit tests bloat our repository and slow down the testing
process. Therefore unless the prime purpose of the algorithms is to load
or save a file then you should not use a file in your unit tests.</p>
<dl class="simple">
<dt>How do I get a workspace filled with data?</dt><dd><p>Firstly you want to think about how much data you really need, unit
tests need to be fast so you don’t want too much data.
Secondly you should use and extend helper classes (like
<a class="reference external" href="https://github.com/mantidproject/mantid/blob/main/Framework/TestHelpers/inc/MantidTestHelpers/WorkspaceCreationHelper.h">1</a>)
to provide the workspaces for you. Keep things as generic as you can
and it will help you and others for other tests.
More details of this will be provided at <a class="reference external" href="TestingUtilities">Testing Utilities</a>.</p>
</dd>
<dt>I want a workspace with a valid instrument definition and Spectra-detector map</dt><dd><p>As above use or extend a method in one of the <a class="reference external" href="TestingUtilities">helper classes</a>
that actually creates a minimal workspace for you in code - it will
only hurt the first time but everyone will benefit.
Loading instrument XML files in debug <strong>really</strong> hurts performance;
avoid this like the plague.</p>
</dd>
<dt>What if it <strong>really</strong> needs a file</dt><dd><p>First justify your reasoning with the PM or Lead developer
Ensure the file is as small as possible. Perhaps edit the file to
only contain 2 spectra
Note: this is not the same as just loading 2 spectra from a large
file.
Do not use a relative path to a file
Used the <a class="reference external" href="https://github.com/mantidproject/mantid/blob/main/Framework/TestHelpers/inc/MantidTestHelpers/ScopedFileHelper.h">Scoped
File</a>
helper, to ensure that resources are cleaned-up in an exception safe
manner.</p>
</dd>
</dl>
</section>
</section>
<section id="mocking">
<h2><a class="toc-backref" href="#id11" role="doc-backlink">Mocking</a><a class="headerlink" href="#mocking" title="Link to this heading">¶</a></h2>
<p>Mocking is a very powerful tool that allows you to simulate components
in your unit environment and check how your code operates within this
environment. Mocking allows you to avoid creating Fake objects of any
kind, and results in fast executing code with a very high test coverage.
See <a class="reference external" href="MVPTutorial/Mocking">Mocking</a> in Mantid to find out what it is and how it
works in Python. Once you are familiar with the general concept, C++ has mocking too - see
<cite>Dependency Injection and Basic Mocking <https://vladris.com/blog/2016/07/06/dependency-injection-in-c.html></cite>.</p>
<figure class="align-default" id="id1">
<img alt="Object under test using Mocking to isolate the testing.|400px" src="_images/Mocking.png" />
<figcaption>
<p><span class="caption-text">Object under test using Mocking to isolate the testing.|400px</span><a class="headerlink" href="#id1" title="Link to this image">¶</a></p>
</figcaption>
</figure>
</section>
</section>
</div>
</div>
</div>
<footer class="footer">
<div class="container">
<ul class="nav navbar-nav" style=" float: right;">
<li>
<a href="DebuggingUnitTests.html" title="Previous Chapter: Debugging Unit Tests"><span class="glyphicon glyphicon-chevron-left visible-sm"></span><span class="hidden-sm hidden-tablet">« Debugging Unit Tests</span>
</a>
</li>
<li>
<a href="ReviewingAPullRequest.html" title="Next Chapter: Reviewing a Pull Request"><span class="glyphicon glyphicon-chevron-right visible-sm"></span><span class="hidden-sm hidden-tablet">Reviewing a P... »</span>
</a>
</li>
<li><a href="#">Back to top</a></li>
</ul>
<p>
</p>
</div>
</footer>
</body>
</html>