Lutger Wrote: > I'm rewriting my testing stuff at the moment, I hoped to use the runtime > features to be able to user regular asserts too but that didn't work out. > > Do you know you can get rid of the need to pass __FILE__ and __LINE__? > > Define the functions this way: > > void expectEquals(T)(T some_x, T some_y, > string file = __FILE__, > int line = __LINE__); > > Default parameter initialization does the right thing here (in D2, dunno > about D1). >
Thanks to everyone for responses; to keep forum churn low if I haven't thanked you please consider yourself thanked ;-) Lutger, I'm using D1.0 and, being an old C++ hacker, immediately tried the default params trick for __FILE__ and __LINE__ but it gave me the info for the called function and not the point of call so seems I'm stuck with the noise unfortunately. Moving on. Extending the JUnit functions set which includes assertTrue, assertGreaterThan et. al. and taking the lead from DUnit to prefix the funcnames with "expect" rather than "assert", I've implemented things like "expectAssertFail" and "expectException" as added tests just to verify that my assert and exception code works. These latter functions take functions and/or delegates as parameters and are wrapped in a try/catch block themselves so that the tests can be continuous. All in all, and taking into account other replies on this thread, me still thinks that the stock-standard D idiom for unit testing is all you need for a decent unit testing regime. Its just a matter of fine tuning your set of "assert-but-don't-bail-out-on-just-one-error" functions. If I haven't misread you, sounds we are on the same track. Cheers Justin
