<br><br><div class="gmail_quote">On Mon, May 20, 2013 at 6:52 PM, Nick Sabalausky <span dir="ltr"><<a href="mailto:SeeWebsiteToContactMe@semitwist.com" target="_blank">SeeWebsiteToContactMe@semitwist.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Y'know what we need? This compiler flag:<br>
<br>
   -unittest=pagkage.name.*<br></blockquote><div><br></div><div>I would like that as well.</div><div><br></div><div>Here's a workaround in the meantime:</div><div><div>dmd -c -unittest a;</div></div><div><div>dmd -c b;</div>
</div><div>dmd -oftest -main -unittest *.o</div><div>./test => will only run unittest of a, not b.</div><div><br></div><div>Another thing we need is named unittests:</div><div><br></div><div>unittest(my_test_1){...}</div>
<div><br></div><div>It's been requested so many times and I still don't get the arguments against them.</div><div>Here's a common workflow:</div><div><br></div><div>1) I write a function fun.</div><div>2) I write a function test_fun that tests fun.</div>
<div>3) I run test_fun in isolation (saves time, only need to run that)</div><div>4) Later on, once its debugged I turn test_fun into a unittest.</div><div><br></div><div>Having unittest(test_fun){...} would simplify this routine.</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Damn near every codebase in D uses "unittest{}" sections. Obviously<br>
that's good.<br>
<br>
But it's also bad:<br>
<br>
I cannot flip on unittests for my project (where "I" and "my" can be<br>
substituted with the name of any D user) without *also* flipping on<br>
unittests for every source-library used, transitively. Unless the lib<br>
versions-out their unittests with "version(Unittest_MyLibXXX)"...And<br>
none of them do. (well, mostly)<br>
<br>
This *can* be fine, *when*:<br>
<br>
- They're all fast.<br>
<br>
- Their sum doesn't make DMD's memory usage go kabloom.<br>
<br>
- They all have all their prereqs already setup (sometimes the need for<br>
  some configuration isn't easily avoidable, example: setting up a DB<br>
  user/login).<br>
<br>
- And none of them have any failures...on the *exact*<br>
  OS/arch/compiler/compiler-version combination that I happen to be<br>
  using. Oh, and the exact versions of any other dependent libs.<br>
<br>
We could say "Let's just recommend good style is to version out your<br>
unittest blocks". But that's programming by convention: All it takes is<br>
one lib not playing ball, or one unittest in one lib that just happened<br>
to forget it, and then the poor user is back to "ad-hoc patching"-land.<br>
And it's boiler-plate, anyway.<br>
<br>
So alright...Who's with me?!!! "Yeaaaa......!!!!!" (<-- Belushi running<br>
out the door)<br>
<br>
</blockquote></div><br>