[TIP] real world testing
dstanek at dstanek.com
Sun Jul 5 09:35:33 PDT 2009
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.
More information about the testing-in-python