[TIP] A quick guide to testing (for the khmer project)

[Terry Peppers]

The only thing I would add in the section about adding tests for new code
is whether or not you give a darn about the type of test itself. Being
ignorant to khmer - and really to much of what you do Dr. Brown - would it
make a different to contributors to understand the differences between a
unit test and say an integration test. Again YMMV with terminology and
usage, but what atomic type of test should someone add if they've added
something new? Unit only? What if that new code touches some other part of
the system, should there be a unit and integration approach.

I have no idea.

It's almost like you say what I just said in your three steps, but I prefer
a more explicit approach and definition to the problem.

My $.02.

- t.


On Wed, Jul 23, 2014 at 10:08 AM, C. Titus Brown <ctb at msu.edu> wrote:

> I teach undergrads, and they are often starting with no version control,
> little Python, highly variable programming experience, and no automated
> testing; it's a complete disaster.  If I had 'em for two terms I could
> do more.
>
> I also work to educate scientists, and while they take to testing like
> ducks
> to water (*slight exaggeration) like many inexperienced programmers the
> combination of VCS, Python, and automated testing sinks them well before
> they get to TDD.
>
> tl; dr? I have lots of experience and am choosing to spend my time on other
> things than teaching TDD :)
>
> --titus
>
> On Wed, Jul 23, 2014 at 03:03:41PM +0000, Marcin Tustin wrote:
> > What have you found is the difficulty in teaching it? The only problems
> I have found in teaching it are that people are unwilling to try it at all.
> Once they try it, they become comfortable with it very quickly.
> >
> > -----Original Message-----
> > From: C. Titus Brown [mailto:ctb at msu.edu]
> > Sent: Wednesday, July 23, 2014 11:03 AM
> > To: Marcin Tustin
> > Cc: tip at lists.idyll.org
> > Subject: Re: [TIP] A quick guide to testing (for the khmer project)
> >
> > Yes, I know how TDD works, but I don't use it on my projects and I've
> found that it is very difficult to teach.  YMMV but there you are :).
> >
> > best,
> > --titus
> >
> > On Wed, Jul 23, 2014 at 03:00:01PM +0000, Marcin Tustin wrote:
> > > This encodes the code first, write tests afterward approach to
> development. It's bad because it's *hard*. It's hard to come up with good
> test cases post hoc, because there's a lot of analysis to do (which is made
> easier when you write the code, because you're already thinking of those
> things), and because code not written to be tested is more difficult to
> test. TDD solves these problems by merging the development and testing
> activities into one step.
> > >
> > > -----Original Message-----
> > > From: testing-in-python-bounces at lists.idyll.org
> > > [mailto:testing-in-python-bounces at lists.idyll.org] On Behalf Of C.
> > > Titus Brown
> > > Sent: Wednesday, July 23, 2014 10:12 AM
> > > To: tip at lists.idyll.org
> > > Subject: [TIP] A quick guide to testing (for the khmer project)
> > >
> > > http://khmer.readthedocs.org/en/docs-hackathon/dev/a-quick-guide-to-te
> > > sting.html
> > >
> > > comments, thoughts?
> > > _______________________________________________
> > > testing-in-python mailing list
> > > testing-in-python at lists.idyll.org
> > > http://lists.idyll.org/listinfo/testing-in-python
> >
> > --
> > C. Titus Brown, ctb at msu.edu
>
> --
> C. Titus Brown, ctb at msu.edu
>
> _______________________________________________
> testing-in-python mailing list
> testing-in-python at lists.idyll.org
> http://lists.idyll.org/listinfo/testing-in-python
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.idyll.org/pipermail/testing-in-python/attachments/20140723/20f4ea32/attachment.htm>