On 2014-04-30 22:41, Andrei Alexandrescu wrote:
Yah I think that's possible but I'd like the name to be part of the
function name as well e.g. unittest__%s.
Why is that necessary? To have the correct symbol name when debugging?
I'm using something quite similar to RSpec from the Ruby world:
describe! "toMsec" in {
it! "returns the time in milliseconds" in {
assert(true);
}
}
This uses the old syntax, with UDA's it becomes something like this:
@describe("toMsec")
{
@it("returns the time in milliseconds") unittest
{
assert(true);
}
}
That looks... interesting.
The Ruby syntax looks like this:
describe "toMsec" do
it "reruns the time in milliseconds" do
assert true
end
context "when the time parameter is nil" do
it "returns nil" do
assert true
end
end
end
The interesting part about the Ruby implementation is that each it-block
(the code between do/end) is executed in the context of an anonymous
class instance. Each describe/context-block is turned in to a class,
nested blocks inherit from the outer block. In D the implementation
would look like this:
class __toMsec
{
void __someUniqueName123 ()
{
}
class __SomeUniqueName456 : __toMsec
{
void __someUniqueName789 ()
{
}
}
}
Each it-block (unit test) will be executed in a new instance of the
closest surrounding class. This means you can have helper methods and
instance variables shared across multiple test, but they will each get a
fresh copy of the data.
Since the describe-blocks are implemented with classes that inherit you
can override helper methods in subclasses.
The unit test runner can also print out a documentation, basically all
text in the "it" and "describe" parameters. Something like this:
https://coderwall-assets-0.s3.amazonaws.com/uploads/picture/file/1949/rspec_html_screen.png
--
/Jacob Carlborg
