unittests are really part of the build, not a special run

[Ary Borenszweig via Digitalmars-d]

On 4/1/15 3:57 PM, Jacob Carlborg wrote:
> On 2015-04-01 20:04, Ary Borenszweig wrote:
>
>> By the way, this is the way we do it in Crystal. The source code
>> for the spec library is here, if you need some inspiration:
>> https://github.com/manastech/crystal/tree/master/src/spec . It's
>> just 687 lines long.
>
> Ahhh, looks like my old buddy RSpec :). Does it do all the fancy things
> with classes, instance and inheritance, that is, each describe block is
> a class an each it block is an instance method?
>

No, it's actually much simpler but less powerful. This is because the 
language is not as dynamic as Ruby. But we'd like to keep things as 
simple as possible.

But right now you get these things:

1. You can generate many tests in a simple way:

~~~
[1, 2, 3].each do |num|
   it "works for #{num}" do
     ...
   end
end
~~~

2. You get a summary of all the failures and the lines of the specs that 
failed. Also, you get errors similar to RSpec for matchers. And you get 
printed a command line for each failing spec so you can rerun it 
separately. These are the most useful RSpec features for me.

3. You can get dots for each spec or the name of the specs (-format option).

4. You can run a spec given its line number or a regular expression for 
its name.

Eventually it will have more features, as the language evolves, but for 
now this has proven to be very useful :-)

Another good thing about it being just a library is that others send 
pull requests and patches, and this is easier to understand than some 
internal logic built into the compiler (compiler code is always harder).