On 06/05/14 20:39, Dicebot wrote:
On Tuesday, 6 May 2014 at 18:28:27 UTC, Jacob Carlborg wrote:
d.
I don't see why would be bad to use "unittest" for integration tests,
except for the misguided name. It's perfectly to place "unittest" is
completely different modules and packages. They don't need to be
placed inline.
Well I am actually guilty of doing exactly that because it allows me to
merge coverage analysis files :) But it is not optimal situation once
you consider something like parallel tests as compiler does not know
which of those blocks are "true" unit tests.
It also makes difficult to define a common "idiomatic" way to organize
testing of D projects. I'd also love to see a test library that helps
with defining integration tests structure (named tests grouped by common
environment requirements doing automatic cleanup upon finishing the
group/block) without resorting to custom classes AND without interfering
with simplicity of existing unittests.
I think it all can be done by keeping existing single "unittest" keyword
but using various annotations. Then integration tests can be done as
separate application that uses imaginary Phobos integration tests
library to interpret those annotations and provide more complex test
structure. And running plain `rdmd -unittest` on actual application
modules will still continue to do the same good old thing.
So you're saying to use the "unittest" keyword but with a UDA?
Something I already do, but for unit tests. Well my idea for a testing
framework would work both for unit tests and other, higher levels of test.
@describe("toMsec")
{
@it("returns the time in milliseconds") unittest
{
assert(true);
}
}
--
/Jacob Carlborg
