<div dir="ltr"><div><div>More specific to this actual test, as I go along adding more entry points for an object, I go back and refactor existing tests to use them.  In the case of NamedBufferData, I started out with just this one line in this one test, but then as I added tests for later entry points, I made them use NamedBufferData as well.<br><br></div>I want the suite of DSA tests to "evolve naturally," ie. hopefully match the way that game developers will use DSA "in the wild" of writing game engines.  DSA functions tend to be used together as a group: CreateTextures with TextureParameter and BindTextureUnit, etc.<br><br></div>Along the way of developing DSA, in the in-between of testing entry points, I test what happens if you mix DSA with non-DSA.<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Feb 19, 2015 at 3:01 PM, Laura Ekstrand <span dir="ltr"><<a href="mailto:laura@jlekstrand.net" target="_blank">laura@jlekstrand.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>The general consensus I've gotten [not specific to this particular test] is that Piglit tests should mostly be functional in nature.  Conformance (as in the types of errors thrown) is tested by the official Khronos conformance suites.  For instance, before I pushed arb_dsa texture objects, Anuj ran gles-3.0 conformance suite on it.<br><br></div>For DSA, when a completely new function is added (such as Create*), I tend to add some conformance tests for that.  (Especially since there isn't much else you can test with Create* if it is the only DSA entry point you have for that type of object.)  For the others, since they share so much code (especially for error-checking) with the traditional entry points, I assume that other tests are doing a more thorough check.  So I mainly add a test or two that tests the function of the new entry point.<br></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Feb 18, 2015 at 9:52 AM, Ilia Mirkin <span dir="ltr"><<a href="mailto:imirkin@alum.mit.edu" target="_blank">imirkin@alum.mit.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Wed, Feb 18, 2015 at 9:59 AM, Martin Peres<br>
<<a href="mailto:martin.peres@linux.intel.com" target="_blank">martin.peres@linux.intel.com</a>> wrote:<br>
[...]<br>
<span>> and you only test the differences you introduced in mesa but is this really<br>
> how<br>
> we are supposed to write the tests?<br>
><br>
> I really don't know, hence why I am asking.<br>
<br>
</span>In case there's any doubt, no, you're supposed to write self-contained<br>
tests that don't in any way rely on mesa impl details, or what other<br>
tests are out there for unrelated features. [And I say this without<br>
making any sort of judgement on the actual test being discussed.]<br>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div>