www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 12473] New: Allow version specification for unittests

reply d-bugmail puremagic.com writes:
https://d.puremagic.com/issues/show_bug.cgi?id=12473

           Summary: Allow version specification for unittests
           Product: D
           Version: D2
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: coffimplib
        AssignedTo: nobody puremagic.com
        ReportedBy: andrej.mitrovich gmail.com


--- Comment #0 from Andrej Mitrovic <andrej.mitrovich gmail.com> 2014-03-26
14:47:36 CET ---
Currently when we want to unittest a library but only under specific conditions
we have to use version blocks. Here's the reason why:

-----
module libfoo;

import std.stdio : File;

///
void someFunc(File file) { }

// test someFunc
unittest
{
    import core.runtime : Runtime;

    string rootPath = Runtime.args[1];  // runtime argument expected!

    import std.path : buildPath;

    auto file = File(rootPath.buildPath("test_file.dat"));
    someFunc(file);
}
-----

Here's the problem with this: If the user of this library also compiles with
-unittest and uses RDMD (to test his client application), the above will fail
because the library expects a specific runtime argument for the path of the
library so it can run its test-suite on some files in the repository.

As a workaround we can use version blocks:

-----
module libfoo;

import std.stdio : File;

///
void someFunc(File file) { }

// test someFunc
version (TestLibFoo) // added
unittest
{
    import core.runtime : Runtime;

    string rootPath = Runtime.args[1];  // runtime argument expected!

    import std.path : buildPath;

    auto file = File(rootPath.buildPath("test_file.dat"));
    someFunc(file);
}
-----

Now when the user builds with -unittest he won't have failures, the library's
unittests are only ran when -version=TestLibFoo.

But I would like a slightly less verbose workaround, by allowing versioned
unittests. In other words:

-----
import std.stdio : File;

///
void someFunc(File file) { }

// test someFunc only if -unittest=TestLibFoo was set
unittest (TestLibFoo)
{
    import core.runtime : Runtime;

    string rootPath = Runtime.args[1]; 

    import std.path : buildPath;

    auto file = File(rootPath.buildPath("test_file.dat"));
    someFunc(file);
}
-----

The unittest block would be enabled if -unittest=TestLibFoo was set.

I think this would make a simple additive change to the language, and it would
make it obvious *what* a switch enables. In other words, you can tell at a
glance that -unittest=PngImage enables a unittest block, rather than to have to
encode this information in a version switch via -version=TestPngImage.

-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Mar 26 2014
next sibling parent d-bugmail puremagic.com writes:
https://d.puremagic.com/issues/show_bug.cgi?id=12473


Vladimir Panteleev <thecybershadow gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |thecybershadow gmail.com


--- Comment #1 from Vladimir Panteleev <thecybershadow gmail.com> 2014-03-26
15:50:52 EET ---
version(unittest) ?

This is the workaround I use:

https://github.com/CyberShadow/ae/blob/master/sys/timing.d#L382-L396

-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Mar 26 2014
prev sibling next sibling parent d-bugmail puremagic.com writes:
https://d.puremagic.com/issues/show_bug.cgi?id=12473


Vladimir Panteleev <thecybershadow gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |thecybershadow gmail.com


--- Comment #1 from Vladimir Panteleev <thecybershadow gmail.com> 2014-03-26
14:50:52 CET ---
version(unittest) ?

This is the workaround I use:

https://github.com/CyberShadow/ae/blob/master/sys/timing.d#L382-L396

--- Comment #2 from Andrej Mitrovic <andrej.mitrovich gmail.com> 2014-03-26
14:51:40 CET ---
There is one bit of ambiguity with the design though, what to do about
version(unittest) blocks. E.g.:

-----
version (??)
void testFoo()
{
}

unittest(TestFoo)
{
    testFoo();
}
-----

What should the first version declaration look like? Maybe:

-----
version (unittest(TestFoo))
void testFoo()
{
}

unittest(TestFoo)
{
    testFoo();
}
-----

-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Mar 26 2014
prev sibling next sibling parent d-bugmail puremagic.com writes:
https://d.puremagic.com/issues/show_bug.cgi?id=12473



--- Comment #3 from Vladimir Panteleev <thecybershadow gmail.com> 2014-03-26
15:53:17 EET ---
Oops, never mind my comment - didn't understand this issue fully.

-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Mar 26 2014
prev sibling next sibling parent d-bugmail puremagic.com writes:
https://d.puremagic.com/issues/show_bug.cgi?id=12473



--- Comment #4 from Andrej Mitrovic <andrej.mitrovich gmail.com> 2014-03-26
14:54:05 CET ---
(In reply to comment #1)
 version(unittest) ?

The issue is these blocks are run if -unittest is set when the client compiles his own codebase that happens to use this library, but these blocks should only be ran when the library is built on its own (because it may require specific runtime arguments). -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Mar 26 2014
prev sibling parent d-bugmail puremagic.com writes:
https://d.puremagic.com/issues/show_bug.cgi?id=12473



--- Comment #5 from Andrej Mitrovic <andrej.mitrovich gmail.com> 2014-03-26
14:54:25 CET ---
(In reply to comment #3)
 Oops, never mind my comment - didn't understand this issue fully.

I may have underspecified it. :) -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Mar 26 2014