<div dir="ltr">I don't think creating new answer tests is hard as such.  What's difficult is setting up the testing environment, uploading new answers to S3, and figuring out how to use the nose answer testing plugin to actually run the tests. I think Kacper mentioned that he could add some jenkins magic to automate most of that process which should ease the burden of adding new answer test results in the future. While I like your idea, I still do think we should be doing quantitative answer testing of all the frontends.<div>

<br></div><div>Do we have datasets for the new 3.0 only frontends?  Can we put them on <a href="http://yt-project.org/data">yt-project.org/data</a>?</div><div><br></div><div>I like your idea and think it nicely integrates some degree of lightweight testing and, more importantly, documents how to use the frontends and validates that accessing them works using the latest and greatest development version of yt.  I see no problem with hosting it under the main yt_analysis account.</div>

</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Aug 28, 2013 at 1:46 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>
I'd like to bring up the topic of frontend tests.<br>
<br>
As it stands, we have answer tests for a few frontends, and a large<br>
amount of sample data for other frontends.  The answer tests are fine,<br>
but they are also somewhat ... difficult to write and come up with.  I<br>
believe that they should still exist inside the main repo.<br>
<br>
However, what I'd like to propose is a new repository<br>
("frontend_tests" perhaps?) that includes scripts for each frontend<br>
that load data, save images, and that we will then *version* a set of<br>
results images and data inside.  This repository will be allowed to<br>
grow larger than we'd like the main yt repository to grow, and it<br>
would also mean that we could use normal pull request mechanisms for<br>
updating results, rather than AWS S3 uploads with keys and so on.<br>
<br>
My idea was that it would include something like a helper function<br>
library (for common routines like "what is the current version of the<br>
code" and "commit a new version of this image") and would also include<br>
image-generating scripts and mechanisms for viewing images.  The idea<br>
is that you would run a script at the top level and it would spit out<br>
a bunch of images or data, and there would be templates of HTML that<br>
you could view old-versus-new.  This could then be integrated into our<br>
CI system (I spoke with Kacper about this previously).  It would serve<br>
two purposes:<br>
<br>
1) Display results as a function of the current iteration (these<br>
results would not be quantitatively assessed; this would be the<br>
function of the answer testing we already have)<br>
2) Tell us if loading a dataset or frontend breaks<br>
3) Light quantitative result analysis<br>
<br>
I'm planning to create a repository similar to this regardless (for<br>
demonstrating frontend scripts) but I'm bringing it to the list to see<br>
if it is alright to host under the main yt_analysis team on Bitbucket<br>
and to integrate into testing.  Does this appeal to anyone?  I imagine<br>
it could be much simpler than creating new answer tests.<br>
<br>
-Matt<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>
</blockquote></div><br></div>