<div>Roland, Erik, <a href="http://et.al/" target="_blank">et.al</a>.</div>
<div>I am not sure if my posting was well understood so I will give an example.</div>
<div> </div>
<div>When one has an extremely complex piece of software that has few tests and there is a need to  be constantly adding new features there are only a couple of ways of testing it. It can not be well tested at the higher levels only at the module level. </div>

<div> </div>
<div>For example, I would liken the testing of GROMACS to a high level language compiler designed with complex syntax, many modules and many options. Compilers have language features, syntax that require runtime support and finction libraries. They also have supporting library routines or support programs. No one would ever try to make a test suite for high level use cases. What is done is to create separate test programs that exercise language syntax that can be tested without direct calls to internal modules or directly to library routines (e.g. nonbonded, etc.). Separate tests programs are written for things like object file creation. These tests have &#39;right&#39; answers. No attempt is made to test &#39;use cases&#39; except in the case of priority 1 bugs. This reduces the scope of testing to a manageable and defined level. It requires breaking the program into functional groups, internal routines and external routines and support programs. This is not difficult to do with GROMACS. GROMACS has .mdp options that amount to &#39;lanaguage&#39; syntax, internal code routines, external programs and file formats like a compiler. This is the test approach that I think should be taken.</div>

<div> </div>
<div>In cases where I have worked on compilers that were &#39;legacy&#39; and mature products we prioritized the removal of all serious P1 and P2 bugs and adding new features. When new features were added developers <em>started</em> adding higher level tests. In response to serious P1 bugs in &#39;broken generated programs&#39; &#39;e.g. simulations&#39; user provided code (or simuations) were added to the test suite. Onces I inherited such a compiler. We had many new features to add, many bugs, little documenation, virtually no test suite and a short time to release. With 5 people we added all the new features in 5 months, fixed all the priority 1 and 2  bugs, and built test programs that exercised or called directly all key core modules.</div>

<div> </div>
<div>I hope this helps.</div>
<div> </div>
<div>Cheers</div>
<div>David</div>
<div> </div>
<div> Sat, Feb 11, 2012 at 7:45 PM, Roland Schulz <span dir="ltr">&lt;<a href="mailto:roland@utk.edu" target="_blank">roland@utk.edu</a>&gt;</span> wrote:<br></div>
<div class="gmail_quote">
<blockquote style="BORDER-LEFT:#ccc 1px solid;MARGIN:0px 0px 0px 0.8ex;PADDING-LEFT:1ex" class="gmail_quote"><br><br>
<div class="gmail_quote">
<div>On Sat, Feb 11, 2012 at 11:31 AM, Shirts, Michael (mrs5pt) <span dir="ltr">&lt;<a href="mailto:mrs5pt@eservices.virginia.edu" target="_blank">mrs5pt@eservices.virginia.edu</a>&gt;</span> wrote:<br></div>
<blockquote style="BORDER-LEFT:#ccc 1px solid;MARGIN:0px 0px 0px 0.8ex;PADDING-LEFT:1ex" class="gmail_quote">
<div>
<div>&gt; 1) Low-level tests that specifically check the output for several sets of<br>&gt; input for a *module*, i.e. calling routines rather than running a simulation.<br>&gt; The point is that this will isolate errors either to a specific module, or to<br>
&gt; modules it depends on. However, when those modules too should have tests it<br>&gt; will be a 5-min job to find what file+routine the bug is likely to be in.<br><br></div></div>
<div>I&#39;m not exactly sure how this works.  If we test modules, we have to be<br>writing a bunch of new code that interacts with the modules directly, and so<br>we may miss things that happen in actual simulation cases.  I sort of favor<br>
just actually running grompp and mdrun, because the errors that occur will<br>be the errors that people actually see. I haven&#39;t found an error yet that is<br>particularly hard to isolate to a given file pretty quickly once it is<br>
identified.   Perhaps for particular aspects things (testing that dozens of<br>inner loops give consistent numbers) this makes sense, but I&#39;m not sure it<br>makes sense for everything.  I&#39;m not sure how you _just_ test pressure<br>
control, for example.<br></div></blockquote>
<div>One could read virial values from a data file and pass it to the pressure control. And then check that the pressure control is behaving as it should. </div>
<div><br></div>
<div>I think unit tests would be very useful for the planned conversion to C++. We will have to convert individual modules one at a time and I assume that the overall program will be broken often. In that case unit tests might enable us to test individual modules without the overall programming working. </div>

<div><br></div>
<div>Roland</div>
<div> </div>
<blockquote style="BORDER-LEFT:#ccc 1px solid;MARGIN:0px 0px 0px 0.8ex;PADDING-LEFT:1ex" class="gmail_quote">
<div>
<div>
<div><br>Best,<br>~~~~~~~~~~~~<br>Michael Shirts<br>Assistant Professor<br>Department of Chemical Engineering<br>University of Virginia<br><a href="mailto:michael.shirts@virginia.edu" target="_blank">michael.shirts@virginia.edu</a><br>
</div><a href="tel:%28434%29-243-1821" target="_blank" value="+14342431821">(434)-243-1821</a> 
<div><br><br><br><br>--<br>gmx-developers mailing list<br><a href="mailto:gmx-developers@gromacs.org" target="_blank">gmx-developers@gromacs.org</a><br><a href="http://lists.gromacs.org/mailman/listinfo/gmx-developers" target="_blank">http://lists.gromacs.org/mailman/listinfo/gmx-developers</a><br>
Please don&#39;t post (un)subscribe requests to the list. Use the<br>www interface or send it to <a href="mailto:gmx-developers-request@gromacs.org" target="_blank">gmx-developers-request@gromacs.org</a>.<br><br><br><br><br>
</div></div></div></blockquote></div>
<div>
<div></div>
<div><br><br clear="all">
<div><br></div>-- <br>ORNL/UT Center for Molecular Biophysics <a href="http://cmb.ornl.gov/" target="_blank">cmb.ornl.gov</a><br><a href="tel:865-241-1537" target="_blank" value="+18652411537">865-241-1537</a>, ORNL PO BOX 2008 MS6309<br>
</div></div><br>--<br>gmx-developers mailing list<br><a href="mailto:gmx-developers@gromacs.org" target="_blank">gmx-developers@gromacs.org</a><br><a href="http://lists.gromacs.org/mailman/listinfo/gmx-developers" target="_blank">http://lists.gromacs.org/mailman/listinfo/gmx-developers</a><br>
Please don&#39;t post (un)subscribe requests to the list. Use the<br>www interface or send it to <a href="mailto:gmx-developers-request@gromacs.org" target="_blank">gmx-developers-request@gromacs.org</a>.<br></blockquote>
</div><br>