Thread overview
exceptions thrown when running app with failed unittests
4 days ago
cym13
4 days ago
Adam D. Ruppe
3 days ago
Jacob Carlborg
4 days ago
Ali Çehreli
4 days ago
Its my 2nd day into D, I am already in deep love (:D),  and I would like to understand whether this is normal behavior or something went terribly wrong, so all help is greatly appreciated.

Following the book of The D Programming language I have the code below:

bool binarySearch(T)(T[] input, T value) {
    while (!input.empty) {
        auto i = input.length / 2;
        auto mid = input[i];
        if (mid > value) input = input[0 .. i];
        else if (mid < value) input = input[i + 1 .. $];
        else return true;
    }
    return false;
}

@safe nothrow unittest {
    assert(binarySearch([ 1, 3, 6, 7, 9, 15 ], 6));
    assert(binarySearch([ 1, 3, 6, 7, 9, 15 ], 5));
}

void main() {

    bool s1 = binarySearch([1, 3, 6, 7, 9, 15], 6);
    bool s2 = binarySearch!(int)([1, 3, 6, 7, 9, 15], 5);
    writeln(s1, s2);
}

Then I compile using the command
$ dmd source/app.d -unittest

and execute as follows
$ ./app

Then the output
core.exception.AssertError@source/app.d(62): unittest failure
----------------
4   app                                 0x000000010b18d1d0 _d_unittest + 152
5   app                                 0x000000010b183d1e void app.__unittest_fail(int) + 38
6   app                                 0x000000010b183df4 nothrow @safe void app.__unittestL60_1() + 184
7   app                                 0x000000010b183ca0 void app.__modtest() + 8
8   app                                 0x000000010b18db54 int core.runtime.runModuleUnitTests().__foreachbody2(object.ModuleInfo*) + 44
9   app                                 0x000000010b186656 int object.ModuleInfo.opApply(scope int delegate(object.ModuleInfo*)).__lambda2(immutable(object.ModuleInfo*)) + 34
10  app                                 0x000000010b1a4471 int rt.minfo.moduleinfos_apply(scope int delegate(immutable(object.ModuleInfo*))).__foreachbody2(ref rt.sections_osx_x86_64.SectionGroup) + 85
11  app                                 0x000000010b1a43fc int rt.minfo.moduleinfos_apply(scope int delegate(immutable(object.ModuleInfo*))) + 32
12  app                                 0x000000010b18662d int object.ModuleInfo.opApply(scope int delegate(object.ModuleInfo*)) + 33
13  app                                 0x000000010b18da3e runModuleUnitTests + 126
14  app                                 0x000000010b19e312 void rt.dmain2._d_run_main(int, char**, extern (C) int function(char[][])*).runAll() + 22
15  app                                 0x000000010b19e2ab void rt.dmain2._d_run_main(int, char**, extern (C) int function(char[][])*).tryExec(scope void delegate()) + 31
16  app                                 0x000000010b19e21e _d_run_main + 458
17  app                                 0x000000010b183d37 main + 15
18  libdyld.dylib                       0x00007fff95f2d254 start + 0
19  ???                                 0x0000000000000000 0x0 + 0


The compiles is
DMD64 D Compiler v2.073.1
Copyright (c) 1999-2016 by Digital Mars written by Walter Bright

and I am executing this on OSX 10.12
4 days ago
On Sunday, 19 March 2017 at 22:13:21 UTC, Ervin Bosenbacher wrote:
> Its my 2nd day into D, I am already in deep love (:D),  and I would like to understand whether this is normal behavior or something went terribly wrong, so all help is greatly appreciated.
>
> [...]

Well, unittests can pass or fail and as the exception states there it failed. Binary search returns true if it found the element in the array, false otherwise. 5 is not an element of [1, 3, 6, 7, 9, 15] so binarySearch returned false. Assert throws an error if its argument is false to it threw. Nothing out of the ordinary except maybe a broken test.
4 days ago
On 03/19/2017 03:13 PM, Ervin Bosenbacher wrote:
> Its my 2nd day into D, I am already in deep love (:D),  and I would like
> to understand whether this is normal behavior or something went terribly
> wrong, so all help is greatly appreciated.
>
> Following the book of The D Programming language I have the code below:
>
> bool binarySearch(T)(T[] input, T value) {
>     while (!input.empty) {
>         auto i = input.length / 2;
>         auto mid = input[i];
>         if (mid > value) input = input[0 .. i];
>         else if (mid < value) input = input[i + 1 .. $];
>         else return true;
>     }
>     return false;
> }
>
> @safe nothrow unittest {
>     assert(binarySearch([ 1, 3, 6, 7, 9, 15 ], 6));

That should return true and the assertion will pass.

>     assert(binarySearch([ 1, 3, 6, 7, 9, 15 ], 5));

Since there is no 5 in the array, that will return false and the assertion will fail, which means that the tests failed.

> }
>
> void main() {
>
>     bool s1 = binarySearch([1, 3, 6, 7, 9, 15], 6);
>     bool s2 = binarySearch!(int)([1, 3, 6, 7, 9, 15], 5);
>     writeln(s1, s2);
> }
>
> Then I compile using the command
> $ dmd source/app.d -unittest
>
> and execute as follows
> $ ./app

So, effectively you requested a unit test run and it failed.

>
> Then the output
> core.exception.AssertError@source/app.d(62): unittest failure
> ----------------

Unless I'm missing something in your question, that's exactly the expected outcome. :)

Ali

4 days ago
On Sunday, 19 March 2017 at 22:20:58 UTC, cym13 wrote:
> On Sunday, 19 March 2017 at 22:13:21 UTC, Ervin Bosenbacher wrote:
>> Its my 2nd day into D, I am already in deep love (:D),  and I would like to understand whether this is normal behavior or something went terribly wrong, so all help is greatly appreciated.
>>
>> [...]
>
> Well, unittests can pass or fail and as the exception states there it failed. Binary search returns true if it found the element in the array, false otherwise. 5 is not an element of [1, 3, 6, 7, 9, 15] so binarySearch returned false. Assert throws an error if its argument is false to it threw. Nothing out of the ordinary except maybe a broken test.

Thank you :) Maybe I need to rephrase. Is it normal to see the long trace output instead of just a failed unit test message?
4 days ago
On Sunday, 19 March 2017 at 22:33:26 UTC, Ervin Bosenbacher wrote:
> On Sunday, 19 March 2017 at 22:20:58 UTC, cym13 wrote:
>> On Sunday, 19 March 2017 at 22:13:21 UTC, Ervin Bosenbacher wrote:
>>> Its my 2nd day into D, I am already in deep love (:D),  and I would like to understand whether this is normal behavior or something went terribly wrong, so all help is greatly appreciated.
>>>
>>> [...]
>>
>> Well, unittests can pass or fail and as the exception states there it failed. Binary search returns true if it found the element in the array, false otherwise. 5 is not an element of [1, 3, 6, 7, 9, 15] so binarySearch returned false. Assert throws an error if its argument is false to it threw. Nothing out of the ordinary except maybe a broken test.
>
> Thank you :) Maybe I need to rephrase. Is it normal to see the long trace output instead of just a failed unit test message?

If someone can just give me more clarifications that would be greatly appreciated. (For some reason I did not think that to see the stack trace is normal)
4 days ago
On Sunday, 19 March 2017 at 22:33:26 UTC, Ervin Bosenbacher wrote:
> Is it normal to see the long trace output instead of just a failed unit test message?

Yeah, it is normal, though IMO useless and ought to just be removed (or at least shortened to just the top few lines).
4 days ago
On Sunday, 19 March 2017 at 23:23:48 UTC, Adam D. Ruppe wrote:
> On Sunday, 19 March 2017 at 22:33:26 UTC, Ervin Bosenbacher wrote:
>> Is it normal to see the long trace output instead of just a failed unit test message?
>
> Yeah, it is normal, though IMO useless and ought to just be removed (or at least shortened to just the top few lines).

Thx Adam.
3 days ago
On 2017-03-20 00:49, Ervin Bosenbacher wrote:
> On Sunday, 19 March 2017 at 23:23:48 UTC, Adam D. Ruppe wrote:
>> On Sunday, 19 March 2017 at 22:33:26 UTC, Ervin Bosenbacher wrote:
>>> Is it normal to see the long trace output instead of just a failed
>>> unit test message?
>>
>> Yeah, it is normal, though IMO useless and ought to just be removed
>> (or at least shortened to just the top few lines).
>
> Thx Adam.

You might want to look at using some unit test framework/library, as unit-threaded [1], which might give you a better experience.

[1] http://code.dlang.org/packages/unit-threaded

-- 
/Jacob Carlborg
3 days ago
On Monday, 20 March 2017 at 07:36:47 UTC, Jacob Carlborg wrote:
> On 2017-03-20 00:49, Ervin Bosenbacher wrote:
>> On Sunday, 19 March 2017 at 23:23:48 UTC, Adam D. Ruppe wrote:
>>> On Sunday, 19 March 2017 at 22:33:26 UTC, Ervin Bosenbacher wrote:
>>>> Is it normal to see the long trace output instead of just a failed
>>>> unit test message?
>>>
>>> Yeah, it is normal, though IMO useless and ought to just be removed
>>> (or at least shortened to just the top few lines).
>>
>> Thx Adam.
>
> You might want to look at using some unit test framework/library, as unit-threaded [1], which might give you a better experience.
>
> [1] http://code.dlang.org/packages/unit-threaded

That is really cool! Thx.