[TIP] real world testing

[David Stanek]

On Sun, Jul 5, 2009 at 9:00 AM, Noah Gift<noah.gift at gmail.com> wrote:
>
>
> On Mon, Jul 6, 2009 at 12:58 AM, Noah Gift <noah.gift at gmail.com> wrote:
>>
>> On Sat, Jul 4, 2009 at 5:48 AM, David Stanek <dstanek at dstanek.com> wrote:
>>>
>>> On Thu, Jul 2, 2009 at 5:37 AM, Noah Gift<noah.gift at gmail.com> wrote:
>>> > I keep going back and forth in swings on very strict 100% code coverage
>>> > vs
>>> > solving problems quickly under 2 day deadlines.  I think so far the 2
>>> > day
>>> > deadline approach wins.  My gut tells me that there is some new theory
>>> > of
>>> > testing that is a bit more real world then the testing Nazi
>>> > approach.....especially in things like web development or film
>>> > production.
>>> >  Comments?
>>
>>  There were a few good comments, like the comment about being able to
>> write a solution in two days because it was built on a libraries that were
>> tested.  In thinking about them and about testing, I can say that I am not
>> 100% sold that you should always write tests for code anymore...as
>> blasphemous as that sounds.  I think it depends.
>> If I am writing a library, an API, or  releasing open source software,
>> then, yes, testing is probably mandatory.  If I need to write a prototype,
>> or solve a problem quickly, then it depends.  In film, for example, you may
>> be asked to solve a problem in 2 days, and the solution could no longer be
>> necessary in 7 days.  If it is necessary to stay in production longer then 7
>> days, then you may just rewrite it, with tests.
>> I think it is important to be truthful to people who haven't yet gotten in
>> the habit of writing tests, that writing tests, depends on the context.
>>  There is no silver bullet...at least I haven't found one.  Sometimes it
>> actually is ok not to write a test, sometimes it isn't, but....it depends.
>>  Another interesting thing is that if you get in the habit of writing code
>> that is easy to test, say, every function returns something that is
>> "assertable", then perhaps you now have written better code, and then as a
>> result testing is less necessary for the context you are working in.
>>

My view is pretty simple. I have never deployed code that was not
tested. In the past I would use the web browser or command line, but
now I replace *some* of that with unit tests. Because of this my
testing has not increased the amount of time it takes to write code.

At first testing did take a bit longer. I have found that this was
because my code wasn't using very good design principles. Once I
started to use the SOLID principles in a consistent way, like SRP and
DIP, I was able to test much more easily. As a consequence my code is
more cohesive and less coupled.

-- 
David
blog: http://www.traceback.org
twitter: http://twitter.com/dstanek