[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