Re: Project Highlight: Funkwerk
On Friday, 28 July 2017 at 21:54:27 UTC, Arun Chandrasekaran wrote: What are they using for HTTP now? Currently, we're using our own utilities, based on https://github.com/dlang/undeaD/blob/master/src/undead/socketstream.d (with the mentioned garbage-collection issue).
depend 0.0.1
https://github.com/funkwerk/depend depend checks actual import dependencies against a PlantUML model of target dependencies. In contrast to dhier, depend makes use of the import dependencies created by dmd with the --deps switch. In our company, we use this tool with CI to guard the development against unintended dependencies.
dunit 0.7.0 released
https://github.com/linkrope/dunit/tree/v0.7.0
The xUnit testing framework for D is used in production for one
year now.
The latest changes are:
- added XML test reporting in JUnitReport format
- dub support
- changed @Ignore to @Ignore(reason to skip the test)
- added assertOp together with corresponding aliases
- added assertEmpty and assertNotEmpty
- extended assertArrayEquals to associative arrays
The XML reporting is currently used for a good integration with
the CI tool Jenkins.
While the dunit/framework is best suited for testing in the
large, dunit/assertion can be used on its own in simple unittest
blocks for improved failure messages:
unittest
{
import dunit.assertion;
assertArrayEquals([1: foo, 2: bar], [1: foo, 2: baz]);
}
You will get the following message:
array mismatch at key 2; expected: bar but was: baz
Even the difference between the string values bar and baz is
highlighted within
(Still, I would wish for something like Python's ndiff for
multi-line string values.)
Re: DUnit: Advanced unit testing toolkit.
On Monday, 23 September 2013 at 16:40:56 UTC, jostly wrote:
I think it's great to see the D unit testing ecosystem growing.
Since it's still relatively small, I think we have a good
chance here to create interoperability between the different
frameworks.
As I see it, we have:
1. Running unit tests
This is where D shines with the builting facility for unit
tests. However, it suffers a bit from the fact that, if we use
assert, it will stop on the first assertion failure, and there
is (as far as I've been able to tell) no reliable way to run
specific code before or after all the unit tests. If I'm wrong
on that assumption, please correct me, that would simplify the
spec running for specd.
In specd, the actual code inside the unittest { } sections only
collect results, and the reporting is called from a main()
supplied by compiling with version specrunner set. I haven't
checked to see if your dunit do something similar.
In my understanding, D's built-in support for unittests is best
suited for test cases that can be expressed as one-liners. When
it gets more complicated, we usually use classes. That's what
JUnit and TestNG do and that's what dunit does (this one:
https://github.com/linkrope/dunit).
For our software, we even separate the 'src' tree from the
'unittest' tree to not distort the coverage results.
2. Asserting results
Varies from the builtin assert() to xUnit-like assertEquals()
to the more verbose x.must.equal(y) used in specd.
This could easily be standardized by letting all custom asserts
throw an AssertError, though I would prefer to use another
exception that encapsulates the expected and actual result, to
help with bridging to reporting.
It's too easy to use 'assertEquals' wrong. JUnit defines
'assertEquals(expected, actual)' while DUnit defines it the other
way around. For JUnit, I've seen too many wrong uses:
'assertEquals(answer, 42)' giving misleading messages expected
... but got 42.
Even with UFCS, why shouldn't you write '42.assertEqual(actual)'?
That's where the more verbose 'must' matchers shine:
'42.must.equal(actual)' is obviously the wrong way around.
When you have violated contracts, you get 'AssertError'
exceptions from deep within your code under test. To fix these
errors you may wish for a stack trace. On the other hand, the
pretty messages you get for failed test assertions should be
enough to fix these failures. In this case, the stack trace would
only show the test runner calling the test case.
So: 'must' matchers are better than 'assert...'; and
'AssertError' should not be thrown for failures!
3. Reporting results
If we have moved beyond basic assert() and use some kind of
unit test runner, then we have the ability to report a summary
of run tests, and which (and how many) failed.
This is one area where IDE integration would be very nice, and
I would very much prefer it if the different unit test
frameworks agreed on one standard unit test runner interface,
so that the IDE integration problem becomes one of adapting
each IDE to one runner interface, instead of adapting each
framework to each IDE.
In my experience from the Java and Scala world, the last point
is the biggest. Users expect to be able to run unit tests and
see the report in whatever standard way their IDE has. In
practice this most often means that various libraries pretend
to be JUnit when it comes to running tests, because JUnit is
supported by all IDEs.
A few days ago, I added such a reporting to dunit. An XML test
report is now available that uses the JUnitReport format. We use
Jenkins (formerly known as Hudson) for continuous integration so
that we can browse our test results and track failures. Nice!
Let's not end up in that situation, but rather work out a
common API to run unit tests, and the D unit test community can
be the envy of every other unit tester. :)
Agreed!
Re: DUnit: Advanced unit testing toolkit.
Same hint as for specd: have a look at 'assertOp'! http://d.puremagic.com/issues/show_bug.cgi?id=4653 alias assertOp! assertGreaterThan; alias assertOp!= assertGreaterThanOrEqual; alias assertOp! assertLessThan; alias assertOp!= assertLessThanOrEqual; avoids duplicate code. Maybe, you can do the same for 'assertStartsWith' and 'assertEndsWith'?
Re: DUnit: Advanced unit testing toolkit.
Have a look at https://github.com/linkrope/dunit, especially at the Related Projects. Until now, my preferred tool for (large-scale) unit testing in D would be the combination of my dunit framework (of course), DMocks-revived for mocks, and the 'must' matchers of specd. How does your toolkit fit in?
Re: specd - write more expressive unit tests
It would be nice to have something like
result.must.not.be!(42);
So, have a look at 'assertOp':
http://d.puremagic.com/issues/show_bug.cgi?id=4653
How can a user of your code add matchers, for example, to check
for elements or attributes in XML? (Without having to change your
code.) The hidden 'MatchStatement' makes the code easy to use but
seems to make it hard to extend. You could add a second
('matcher') parameter to 'must', but then you have to switch from
'.' to '('...')':
result.must(haveTag(root));
By the way: Does the color output work on Windows?
Here is what I do to color the unit-test results:
https://github.com/linkrope/dunit/blob/master/dunit/color.d
Re: Unit Threaded - a unit testing library for D
On Tuesday, 27 August 2013 at 15:42:28 UTC, Andrej Mitrovic wrote: I have some of these functions here: https://github.com/AndrejMitrovic/minilib/blob/master/src/minilib/core/test.d Where is your 'assertOp' from the comments of issue 4653? I recently added it to https://github.com/linkrope/dunit
Re: DUnit - class MyTest { mixin TestMixin; void testMethod1() {} void testMethod2() {}}
Add some variable to the test case: bool finished;
Set the variable in the callback: finished = true;
Add something like
assertWithTimeout({return finished;});
at the end of the test case, following ev.run;
Does it help?
On Wednesday, 29 August 2012 at 19:20:25 UTC, Shripad K wrote:
How do I test callbacks/delegates which are not triggered
immediately? Especially when I need to do unit tests with an
event loop?
A simple example from my codebase (SaaSy here is a custom HTTP
client to an API endpoint):
class TestSaaSy {
mixin TestMixin;
// this works
void test_encoded_auth() {
auto ev = new EventLoop;
auto saasy = new SaaSy(ev, test, test);
assert(saasy.encoded_auth == dGVzdDp0ZXN0dGVzdA==,
encoding issue);
ev.close;
ev.run;
}
// won't work. test gets finished even before the callback
is fired!
void test_get_subscription() {
auto ev = new EventLoop;
auto saasy = new SaaSy(ev, test, test);
saasy.getSubscription(ref363466, (bool err, string
response) {
assert(err == true);
ev.close;
});
ev.run;
}
}
