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

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.

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

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?

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)

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).

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.

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

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.