digitalmars.D.learn - unittest questions
- Johannes Pfau (33/33) Aug 19 2010 Hi, I wrote some unittests using the built-in d unittest and a came
- bearophile (4/7) Aug 19 2010 You may define it outside the unittest{} block (that is a function) and ...
- Simen kjaeraas (19/50) Aug 19 2010 You can use version statements[1] to place the function outside the
- Jonathan M Davis (4/39) Aug 19 2010 If you declare a nested function as static, it shouldn't be a delegate. ...
- Johannes Pfau (5/9) Aug 20 2010 Thanks for all the answers. I guess I'll just declare the functions as
- Steven Schveighoffer (27/58) Aug 23 2010 I know others have answered this, but to aid in your understanding of
Hi, I wrote some unittests using the built-in d unittest and a came across 2 problems: 1) I have some code that accepts both delegates and functions. How can a unittest explicitly check the function part? Whenever I add a function in an unittest block it becomes a delegate. --------------------------------------------------- void add(T)(T handler) if (is(T == void function())){} void add(T)(T handler) if (is(T == void delegate())){} unittest { //always a delegate void handler() {}; add(&handler); } ---------------------------------------------------- 2) I know Errors should not be caught. But when I expect a function to throw in debug mode, but not necessarily in release mode (assert), I have to check for both Errors and Exceptions --> Throwable. Is it OK to catch Throwables in this case? ---------------------------------------------------- unittest { void handler() {}; bool thrown = false; try add(&handler); catch(Throwable) thrown = true; assert(thrown); } ---------------------------------------------------- -- Johannes Pfau
Aug 19 2010
Johannes Pfau:1) I have some code that accepts both delegates and functions. How can a unittest explicitly check the function part? Whenever I add a function in an unittest block it becomes a delegate.You may define it outside the unittest{} block (that is a function) and wrap everything inside a version(unittest){} block. Bye, bearophile
Aug 19 2010
Johannes Pfau <spam example.com> wrote:Hi, I wrote some unittests using the built-in d unittest and a came across 2 problems: 1) I have some code that accepts both delegates and functions. How can a unittest explicitly check the function part? Whenever I add a function in an unittest block it becomes a delegate. --------------------------------------------------- void add(T)(T handler) if (is(T == void function())){} void add(T)(T handler) if (is(T == void delegate())){} unittest { //always a delegate void handler() {}; add(&handler); } ----------------------------------------------------You can use version statements[1] to place the function outside the unittest scope: version( unittest ) { void handler() {} } unittest { add( &handler ); } You could also use function literals[2]: unittest { add( function void() {} ); }2) I know Errors should not be caught. But when I expect a function to throw in debug mode, but not necessarily in release mode (assert), I have to check for both Errors and Exceptions --> Throwable. Is it OK to catch Throwables in this case? ---------------------------------------------------- unittest { void handler() {}; bool thrown = false; try add(&handler); catch(Throwable) thrown = true; assert(thrown); } ----------------------------------------------------Yes. [1]: http://www.digitalmars.com/d/2.0/version.html#version http://www.digitalmars.com/d/2.0/version.html#PredefinedVersions [2]: http://www.digitalmars.com/d/2.0/expression.html#FunctionLiteral -- Simen
Aug 19 2010
On Thursday, August 19, 2010 11:08:33 Johannes Pfau wrote:Hi, I wrote some unittests using the built-in d unittest and a came across 2 problems: 1) I have some code that accepts both delegates and functions. How can a unittest explicitly check the function part? Whenever I add a function in an unittest block it becomes a delegate. --------------------------------------------------- void add(T)(T handler) if (is(T == void function())){} void add(T)(T handler) if (is(T == void delegate())){} unittest { //always a delegate void handler() {}; add(&handler); } ---------------------------------------------------- 2) I know Errors should not be caught. But when I expect a function to throw in debug mode, but not necessarily in release mode (assert), I have to check for both Errors and Exceptions --> Throwable. Is it OK to catch Throwables in this case? ---------------------------------------------------- unittest { void handler() {}; bool thrown = false; try add(&handler); catch(Throwable) thrown = true; assert(thrown); } ----------------------------------------------------If you declare a nested function as static, it shouldn't be a delegate. Also, I don't believe that you need the semicolon after the function declaration. - Jonathan m Davis
Aug 19 2010
On 20.08.2010 01:17, Jonathan M Davis wrote:If you declare a nested function as static, it shouldn't be a delegate. Also, I don't believe that you need the semicolon after the function declaration. - Jonathan m DavisThanks for all the answers. I guess I'll just declare the functions as static, that seems to be the best solution. -- Johannes Pfau
Aug 20 2010
On Thu, 19 Aug 2010 14:08:33 -0400, Johannes Pfau <spam example.com> wrote:Hi, I wrote some unittests using the built-in d unittest and a came across 2 problems: 1) I have some code that accepts both delegates and functions. How can a unittest explicitly check the function part? Whenever I add a function in an unittest block it becomes a delegate. --------------------------------------------------- void add(T)(T handler) if (is(T == void function())){} void add(T)(T handler) if (is(T == void delegate())){} unittest { //always a delegate void handler() {}; add(&handler); } ----------------------------------------------------I know others have answered this, but to aid in your understanding of *why* it works this way, a unittest block is actually a function itself. So declaring a function inside it is like declaring a nested function. In essence, the compiler lumps together all of your unit test blocks into one function per module, and stores a pointer to that function in a ModuleInfo object. Then the runtime calls all of these functions on startup.2) I know Errors should not be caught. But when I expect a function to throw in debug mode, but not necessarily in release mode (assert), I have to check for both Errors and Exceptions --> Throwable. Is it OK to catch Throwables in this case? ---------------------------------------------------- unittest { void handler() {}; bool thrown = false; try add(&handler); catch(Throwable) thrown = true; assert(thrown); } ----------------------------------------------------I'd say that the appropriate thing to do here is to catch the exceptions you would expect to be thrown i.e.: unittest { void handler() {}; bool thrown = false; try add(&handler); catch(DerivedFromException) thrown = true; catch(DerivedFromError) thrown = true; assert(thrown); } ideally, you should be able to predict which exception gets thrown so you only have one catch statement. The point of unit tests are to ensure behavior is within specifications. If your specification is that a function can throw anything, then I think the specification needs work. -Steve
Aug 23 2010