[dmd-internals] changeset 455

Jason House jason.james.house at gmail.com
Wed Apr 28 07:56:49 PDT 2010


Simply running all tests is necessary but not sufficient. After  
running hundreds of thousands of tests, there needs to be any easy way  
to figure out which tests failed and review their failure.

Just as an example, I started a project last week at work, and my  
current test suite has:
  • 250 passing tests. These are regression tests.
  • 22 tests that fail but represent current out of scope features so  
should continue to fail
  • 24 failing tests for work-in-progress changes. These are the main  
focus of current effort (AKA test-driven-development)

Sent from my iPhone

On Apr 28, 2010, at 9:26 AM, Walter Bright <walter at digitalmars.com>  
wrote:

> I've been meaning to do this for a while, just didn't have the time.  
> Also, at the ACCU conference, there were a lot of very experienced  
> people with unit tests, and they were pretty clear that the only  
> significant problem with D's unit test facility was not being able  
> to get all the failures in one run.
>
> Bernard Helyer wrote:
>> On 28/04/10 17:42, Walter Bright wrote:
>>> Due to popular demand, now all unittests run, even if some of them  
>>> fail.
>>>
>>> No source code changes necessary. Requires a corresponding update  
>>> to druntime.
>>>
>>>
>>
>> Wooo! This makes me very happy. Combined with Robert's work on the  
>> DWARF output, my birthday is five months early, it seems.
>>
> _______________________________________________
> dmd-internals mailing list
> dmd-internals at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-internals


More information about the dmd-internals mailing list