Breaking changes in Visual C++ 2015

[Jacob Carlborg via Digitalmars-d]

On 2015-05-08 12:43, Walter Bright wrote:

> I've never seen any as easy to use as D's, and that includes Ruby. Easy
> to use is what makes it a game changer, because people are much more
> likely to use it.

As I've said, it's available in Ruby standard library, but perhaps 
that's not enough built-in for you.

Here's a simple Ruby unit test:

require 'minitest/autorun'

class TestMeme < MiniTest::Unit::TestCase
   def test_foo
     assert 1 == 1
   end
end

Run with "ruby foo.rb"

The D version:

module foo;

unittest
{
     assert(1 == 1);
}

Run with "dmd -main -unittest -run foo.d"

The Ruby version is slightly more complicated to type but easier to run. 
It's the opposite with D. The Ruby version will give you, out of the box:

* A nice report
* A bunch of assertions
* Setup and tear down methods
* Runs all tests even if a previous one failed

And some other stuff as well.

> I know from long experience that when a test framework comes with a
> manual, people tend to not use it. It's just the way people are. If it's
> not builtin, people also tend not to use it.
>
> I'm not claiming D has invented unit testing, nor that it is
> sophisticated. But it is trivial to use, and getting people to actually
> use it is what matters. It's like exercise - just getting out and doing
> something, anything, regularly is 90% of it.
>
> It doesn't matter how sophisticated a testing and coverage tool is if
> people aren't using it as a matter of course. I've seen enough tool
> manuals sitting on programmers' shelves for years still in their shrink
> wrap.
>
> For example, a well-known Ruby project, Rails. Picking a file pretty
> much at random:
>
> https://github.com/rails/rails/blob/master/actionmailer/lib/action_mailer/base.rb
>
>
> No unit tests in it. Poking around, I found this:
>
> https://github.com/rails/rails/blob/master/actionmailer/test/base_test.rb
>
> in another directory. I presume those are the tests for base.rb.

Yes.

> Why can't the tests be in base.rb?

It's the convention used in Ruby. It's perfectly possible to put the 
unit tests in the same file as the implementation, there's no technical 
limitation.

What do you do in D when it comes to integration and functional tests 
that test functionality across several modules?

In Ruby the convention is already to put the tests in the "test" 
directory so there's no special considerations in Ruby.

> I assume there is some 3rd file that connects the two.

Rails uses something called auto loading. If it can't find a class it 
will automatically try to require a file based on a convention. For 
plain Ruby you would just require whatever you want to test, as you 
would do in D, if you used a separate module.

> I really like having the unit tests adjacent to the
> function under test, for the same reason that the Ddoc is adjacent. It
> sounds trite, but having them all together and not in some other file
> hierarchy is a game changer. It certainly changed things in D (before
> Ddoc, Phobos documentation was an utter disaster).

I never liked to have the tests in the same file as the implementation. 
There's also all other kinds of tests that doesn't have a obvious 
implementation module to put them in. But Phobos doesn't have those kind 
of tests so the problem is avoided.

> DMD has a set of source files in one directory, and test files in
> another. There's no obvious correspondence between code and its
> corresponding test.

No, not the way those tests are written. But those are not unit tests, 
they're full stack tests.

> We don't actually know how good the test coverage
> is. I'm very much looking forward to ddmd in order to address this. I
> expect this will result in a large increase in quality.


-- 
/Jacob Carlborg