[brailleblaster] Re: [liblouis-liblouisxml] Re: Test Driven Development (Design)
- From: "qubit" <lauraeaves@xxxxxxxxx>
- To: <brailleblaster@xxxxxxxxxxxxx>
- Date: Wed, 8 Dec 2010 19:55:54 -0600
I agree actually. I always thought unit tests were written by developers to
test not just the whole program, but submodules. The programmer has some
idea of what code is likely to break and hence can write the tests that
apply. Having an independent tester writing additional tests can catch the
bugs that the developers didn't foresee -- either within a module or
interaction between modules. That is why unit tests are written by the
developers and the general stress tests are done independently by someone
else.
Hmm. I never did have time to read the TDD article. Does that stand for
test driven development? If so, I think it applies to brailleblaster.
--le
----- Original Message -----
From: "Michael Whapples" <mwhapples@xxxxxxx>
To: <brailleblaster@xxxxxxxxxxxxx>
Sent: Wednesday, December 08, 2010 3:03 PM
Subject: [brailleblaster] Re: [liblouis-liblouisxml] Re: Test Driven
Development (Design)
I would say, don't look at it from a time angle, the real benefits are
tests for all code written (only useful if tests are good) and the
quality of design as thinking about how you can check something is right
before you have something to test means you must consider what you will
write more carefully and in more detail.
I don't quite know how the idea of having someone writing the tests and
someone writing the product code would work in TDD, for the simple
reason you must write the test before you write the code and then you
look to refactor the code afterwards to try and make it simpler and this
may involve refactoring the tests. I think writing tests and writing
product code become one activity in TDD.
One of the risks I think which would be faced by splitting test writing
and product code writing would be that if those writing product code get
ahead of those writing tests, either you have people sitting around
twiddling thumbs or you have product code written before tests and so
break from TDD and may be loose the tests from that code.
Michael Whapples
On 08/12/10 20:08, John J. Boyer wrote:
> Good points. I'm sending a blind copy of this correspondence to the
> brailleblaster list for those who aren't also on this one.
>
> Is anyone interested in concentrating on writing the tests?
> On Wed, Dec 08, 2010 at 09:39:14AM -0800, Chris von See wrote:
>> Using TDD will lengthen the development timeline a bit since you'll be
>> writing both product code and test code (plus you may be maintaining
>> the tests from time to time if/when your functional specification
>> changes) but it will significantly shorten the debugging process since
>> you'll be able to more readily debug individual portions of the code
>> and you'll catch and localize functional regressions much more
>> quickly. If you can find people that can focus on writing the tests
>> themselves while others write the actual code in parallel you may be
>> able to capture back some of that time...
>>
>> Cheers
>> Chris
>>
>>
>> On Dec 7, 2010, at 9:45 PM, John J. Boyer wrote:
>>
>>> I think some on this list may be familiar with this technique. The
>>> subject has recently come up on the brailleblaster@xxxxxxxxxxxxx list.
>>> Will this approach significantly shorten the time to getting a usable
>>> application?
>>>
>>> Thanks,
>>> John
>>>
>>> --
>>> John J. Boyer; President, Chief Software Developer
>>> Abilitiessoft, Inc.
>>> http://www.abilitiessoft.com
>>> Madison, Wisconsin USA
>>> Developing software for people with disabilities
>>>
>>> For a description of the software, to download it and links to
>>> project pages go to http://www.abilitiessoft.com
>> For a description of the software, to download it and links to
>> project pages go to http://www.abilitiessoft.com
Other related posts:
