<p>Why do I always get these emails right before I have to get on a plane?! I'll write a more detailed response soon....</p>
<div class="gmail_quote">On Sep 21, 2012 6:16 PM, "Casey W. Stark" <<a href="mailto:caseywstark@gmail.com">caseywstark@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi Matt.<div><br></div><div>I would like to help with this, but it's difficult to figure out where to start.</div><div><br></div><div>Say I want to test projections. I make a fake 3D density field, maybe something as simple as np.arange(4**3).reshape((4, 4, 4)). I write down the answer to the x-projection. Now all I need to do is call assert_allclose(yt_result, answer, rtol=1e-15), but I don't know what pieces of low-level yt stuff to call to get to `yt_result`. Hopefully that's clear...</div>
<div><br></div><div>Maybe this comes down to creating a fake frontend we can attach fields to?</div><div><br></div><div>- Casey</div><div><br></div><div><br><div class="gmail_quote">On Fri, Sep 21, 2012 at 2:42 PM, Matthew Turk <span dir="ltr"><<a href="mailto:matthewturk@gmail.com" target="_blank">matthewturk@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi all,<br>
<br>
As some of you have seen (at least Stephen), I filed a ticket this<br>
morning about increasing testing coverage. The other night Anthony<br>
and I met up in NYC and he had something of an "intervention" about<br>
the sufficiency of answer testing for yt; it didn't take too much work<br>
on his part to convince me that we should be testing not just against<br>
a gold standard, but also performing unit tests. In the past I had<br>
eschewed unit testing simply because the task of mocking data was<br>
quite tricky, and by adding tests that use smaller bits we could cover<br>
unit testable areas with answer testing.<br>
<br>
But, this isn't really a good strategy. Let's move to having both.<br>
The testing infrastructure he recommends is the nearly-omnipresent<br>
nose:<br>
<br>
<a href="http://nose.readthedocs.org/en/latest/" target="_blank">http://nose.readthedocs.org/en/latest/</a><br>
<br>
The ticket to track this is here:<br>
<br>
<a href="https://bitbucket.org/yt_analysis/yt/issue/426/increase-unit-test-coverage" target="_blank">https://bitbucket.org/yt_analysis/yt/issue/426/increase-unit-test-coverage</a><br>
<br>
There are a couple sub-items here:<br>
<br>
1) NumPy's nose test plugins provide a lot of necessary functionality<br>
that we have reimplemented in the answer testing utilities. I'd like<br>
to start using the numpy plugins, which include things like<br>
conditional test execution, array comparisons, "slow" tests, etc etc.<br>
2) We can evaluate, using conditional test execution, moving to nose<br>
for answer testing. But that's not on the agenda now.<br>
3) Writing tests for nose is super easy, and running them is too. Just do:<br>
<br>
nosetest -w yt/<br>
<br>
when in your source directory.<br>
<br>
4) I've written a simple sample here:<br>
<br>
<a href="https://bitbucket.org/yt_analysis/yt-3.0/src/da10ffc17f6d/yt/utilities/tests/test_interpolators.py" target="_blank">https://bitbucket.org/yt_analysis/yt-3.0/src/da10ffc17f6d/yt/utilities/tests/test_interpolators.py</a><br>
<br>
5) I'll handle writing up some mock data that doesn't require shipping<br>
lots of binary files, which can then be used for checking things that<br>
absolutely require hierarchies.<br>
<br>
--<br>
<br>
The way to organize tests is easy. Inside each directory with<br>
testable items create a new directory called "tests", and in here toss<br>
some scripts. You can stick a bunch of functions in those scripts.<br>
<br>
Anyway, I'm going to start writing more of these (in the main yt repo,<br>
and this change will be grafted there as well) and I'll write back<br>
once the data mocking is ready. I'd like it if we started encouraging<br>
or even mandating simple tests (and/or answer tests) for functionality<br>
that gets added, but that's a discussion that should be held<br>
separately.<br>
<br>
The items on the ticket:<br>
<br>
* kD-tree for nearest neighbor<br>
* Geometric selection routines<br>
* Profiles<br>
* Projections -- underlying quadtree<br>
* Data object selection of data containers<br>
* Data object selection of points<br>
* Orientation class<br>
* Pixelization<br>
* Color maps<br>
* PNG writing<br>
<br>
Is anyone willing to claim any additional items that they will help<br>
write unit tests for?<br>
<br>
-Matt<br>
_______________________________________________<br>
yt-dev mailing list<br>
<a href="mailto:yt-dev@lists.spacepope.org" target="_blank">yt-dev@lists.spacepope.org</a><br>
<a href="http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org" target="_blank">http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org</a><br>
</blockquote></div><br></div>
<br>_______________________________________________<br>
yt-dev mailing list<br>
<a href="mailto:yt-dev@lists.spacepope.org">yt-dev@lists.spacepope.org</a><br>
<a href="http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org" target="_blank">http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org</a><br>
<br></blockquote></div>