Breaking changes in Visual C++ 2015

[Walter Bright via Digitalmars-d]

On 5/8/2015 1:33 AM, Jacob Carlborg wrote:
> On 2015-05-08 09:55, Walter Bright wrote:
>
>> On the other hand, D's builtin unit testing is so effective it has been
>> a game changer, in that it has successfully changed the culture of D
>> programming.
>
> Perhaps compared to C++ or previous D code. But compared to Ruby it's certainly
> not a game changer and has a long way to go.

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.

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. Why can't the 
tests be in base.rb? I assume there is some 3rd file that connects the two. 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).

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