On Friday, September 23, 2016 23:50:03 Nick Sabalausky via Digitalmars-d wrote: > On 09/23/2016 11:47 PM, Nick Sabalausky wrote: > > On 09/23/2016 07:57 PM, Jonathan M Davis via Digitalmars-d wrote: > >> On Friday, September 23, 2016 16:57:49 Nick Sabalausky via Digitalmars-d > >> > >> wrote: > >>> So...umm...yea...whatever happened to that beefed-up "assert" feature? > >> > >> [...] > > > > Ugh, so, "It was rejected for being library instead of assert, then it > > was rejected for being assert instead of library". > > > > /facepalm
Indeed. :( > > Guess I'll just have to try getting used to awful Java-isms like > > x.notEqual(y) :( > > And then that leads too, to the question of whether such third-party > asserts are a good idea for the doc unittests I like so much... :/ I'd say not. If you're writing a library for general consumption, I don't think that anyone else who is not actually helping to develop it should have to know or care what unit testing facilities you're using. assert is universal and clear, whereas other stuff is not universal and may or may not be clear to those not familiar with it. Also, my take on it is that ddoc-ed unittest blocks are really there to just give examples for the documentation, not to test your code. You want the examples tested so that you know that they work - which is why ddoc-ed unittest blocks are such a great feature - but it's not their purpose to test your library. It would be wholly unreasonable to have thorough tests in the documentation, and what makes a good example doesn't necessarily make for a very good test (or vice versa). So, you can just use basic assertions in your examples without really impacting your actual tests. You then have separate unittest blocks that have the full set of tests needed to verify full functionality, and those can use whatever unit testing tools you prefer without affecting anyone reading the documentation. - Jonathan M Davis
