On 2013-11-06 22:26, Dicebot wrote:
You need only symbol name of your root compiled module which imports all
others. All imported ones will be available in its member list, exactly
what this snippet shows.
That is the problem. One needs to import all other modules. That's not a
good solution
On 2013-11-06 23:33, Gary Willoughby wrote:
foreach (module_; ModuleInfo)
{
auto func = module_.unitTest;
func(); // run tests;
}
The above code retrieves all of the current project's modules and then
grabs each module's unit test blocks. The only trouble is that the
module's unit
Am 07.11.2013 09:37, schrieb Jacob Carlborg:
On 2013-11-06 22:26, Dicebot wrote:
You need only symbol name of your root compiled module which imports all
others. All imported ones will be available in its member list, exactly
what this snippet shows.
That is the problem. One needs to import
On Thursday, 7 November 2013 at 10:04:57 UTC, Sönke Ludwig wrote:
Can't you do something like this? Or is the unit test framework
supposed to provide its own root/main module?
...
void runTests(string root_module = __MODULE__)()
{
// start recursion from root_module
}
---
Only issue is
On Thursday, 7 November 2013 at 12:07:40 UTC, Dicebot wrote:
Only issue is .di file usage - you can't access implementation
declarations when importing those via compile-time reflection.
Other than that I don't see any possible failure sources.
As there is also an issue of having modules a
On Thursday, 7 November 2013 at 08:37:02 UTC, Jacob Carlborg
wrote:
That is the problem. One needs to import all other modules.
That's not a good solution when creating a unit test framework.
One would basically have to scan a directory for all D files.
Then generate a new file that imports
On 2013-11-07 13:22, Dicebot wrote:
I don't see this much an issue as expect good testing framework to be
coupled with a build system anyway. Also in really _lot_ of programs
simply adding mixin to your `app.d` / `main.d` is enough as everything
else is transitively imported from there.
That
On Thursday, 7 November 2013 at 15:03:40 UTC, Jacob Carlborg
wrote:
That doesn't work with libraries. You can have a library
consisting of two separate files that doesn't import each other.
I also prefer to put my tests in its own files, in a separate
directory. They are not imported by any
As part of developing the DUnit framework i'm looking into
executing the unit test at a more fine grain level. The new
'getUnitTests' trait looks interesting but it's value is a symbol
of an aggregate (e.g. struct/class/module).
foreach (module_; ModuleInfo)
{
module aaa;
import std.string;
template Alias(alias S)
{
alias Alias = S;
}
void main()
{
import std.string;
foreach (symbol_name; __traits(allMembers, aaa))
{
alias symbol = Alias!(__traits(getMember, aaa, symbol_name));
On Wednesday, 6 November 2013 at 21:07:47 UTC, Gary Willoughby
wrote:
Unfortunately this still suffers the same problem in that you
need a module symbol name to do anything. I need to get all
module symbols at compile time.
You need only symbol name of your root compiled module which
imports
On Wednesday, 6 November 2013 at 21:26:09 UTC, Dicebot wrote:
On Wednesday, 6 November 2013 at 21:07:47 UTC, Gary Willoughby
wrote:
Unfortunately this still suffers the same problem in that you
need a module symbol name to do anything. I need to get all
module symbols at compile time.
You
On Wednesday, 6 November 2013 at 21:36:52 UTC, Daniel Davidson
wrote:
I don't think it works that way, as how could a compile time
test module know about modules that have pulled it in?
Exactly. __traits work during compile-time. If module is not
imported, it is not known during compile-time
foreach (module_; ModuleInfo)
{
auto func = module_.unitTest;
func(); // run tests;
}
The above code retrieves all of the current project's modules and
then grabs each module's unit test blocks. The only trouble is
that the module's unit tests are kinda rolled into one function
as
On Wednesday, 6 November 2013 at 22:33:48 UTC, Gary Willoughby
wrote:
The above code retrieves all of the current project's modules
and then grabs each module's unit test blocks. The only trouble
is that the module's unit tests are kinda rolled into one
function as show by the 'func' variable
15 matches
Mail list logo
