public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Rick Wesson <rick@support-intelligence.com>
To: Mike Hearn <mike@plan99.net>
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Seeking advice: Encouraging bug-fixing over new features
Date: Sat, 30 Jul 2011 07:06:28 -0700	[thread overview]
Message-ID: <CAJ1JLttSv5RgKAfhOK-4k341NDuA+j4bsPgPWtO2Lxky6--e1w@mail.gmail.com> (raw)
In-Reply-To: <CANEZrP00+5GSPqoKmZgCw1huYNEuidjWgKGDdF-LG-zTaV8xXg@mail.gmail.com>

+1

Putting a bounty on the test framework might put some loose change to work.

http://code.google.com/p/googletest/ would be my choice

the list of c++ frameworks is at
http://en.wikipedia.org/wiki/List_of_unit_testing_frameworks#C.2B.2B

-rick

On Sat, Jul 30, 2011 at 4:49 AM, Mike Hearn <mike@plan99.net> wrote:
> I've worked on open source projects for over 10 years now. This
> dynamic always exists but I've never seen it seriously kill a project.
>
> Thoughts:
>
>  - People who start out with features often stick around and become
> core contributors.
>  - Unit tests are critical.
>
> Now there's a basic skeleton for unit tests, the bug debt can start to
> be paid down by insisting that anyone who touches a piece of code
> introduces tests, whether it be for new features or refactorings.
> Insist patches won't be accepted without some new tests. In an
> untested codebase, adding or improving tests often reveals other bugs
> that then get fixed at the same time.
>
> People usually don't want to write tests if there's nothing there
> already. So I'd suggest seeding the test suite with a small number of
> simple tests for each part (wallet, net, db, etc). Once there are a
> few tests already it's easier to get people to add more. It's tempting
> to say, well, the wallet or re-org handling or whatever is the most
> critical so we'll write lots of tests for that first and do the rest
> later, but that's not as conducive to getting people to help.
>
> Most complex projects need some unit testing infrastructure to assist.
> For instance, the ability to use mock network connections or minimal
> difficulty chains. So if you build up that infrastructure and plant
> those seeds, it'll be easier for other people to flesh it out.
>
> Final thought - big test suites take a long time to grow, especially
> in codebases developed without them. A good start is a manually
> written test plan, that just walks you through the apps features.
> Insisting that a patch be signed off as passing the test plan is a
> good way to avoid gigantic breakages like the wallet encryption bug
> from cold start, at the cost of slowing down development (nobody likes
> doing manual test work over and over).
>
> I don't always follow my own advice on this and usually end up
> regretting it ....
>
> ------------------------------------------------------------------------------
> Got Input?   Slashdot Needs You.
> Take our quick survey online.  Come on, we don't ask for help often.
> Plus, you'll get a chance to win $100 to spend on ThinkGeek.
> http://p.sf.net/sfu/slashdot-survey
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>



  reply	other threads:[~2011-07-30 14:06 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-07-27  1:31 [Bitcoin-development] Seeking advice: Encouraging bug-fixing over new features Gavin Andresen
2011-07-27  6:40 ` John Smith
2011-07-27 11:14   ` Joel Joonatan Kaartinen
2011-07-27 14:20     ` John Smith
2011-07-27 14:28       ` Luke-Jr
2011-07-27 14:42         ` Joel Joonatan Kaartinen
2011-07-27 14:53           ` John Smith
2011-07-27 16:02             ` Douglas Huff
2011-07-27 16:07         ` Rick Wesson
2011-07-27 16:47           ` Matt Corallo
2011-07-27 17:11           ` John Smith
2011-07-27 17:15           ` Joel Joonatan Kaartinen
2011-07-27 22:45             ` Gavin Andresen
2011-07-27 22:54               ` Joel Joonatan Kaartinen
2011-07-27 23:07               ` Matt Corallo
2011-07-28  6:31                 ` John Smith
2011-07-28  0:15               ` Jeff Garzik
2011-07-28 15:37                 ` Caleb James DeLisle
     [not found]       ` <1311811317.72375.YahooMailNeo@web121005.mail.ne1.yahoo.com>
2011-07-28  0:02         ` [Bitcoin-development] Fw: " Amir Taaki
2011-07-30 11:49 ` [Bitcoin-development] " Mike Hearn
2011-07-30 14:06   ` Rick Wesson [this message]
2011-07-30 14:07     ` Matt Corallo
2011-08-03  1:41 ` David Schwartz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAJ1JLttSv5RgKAfhOK-4k341NDuA+j4bsPgPWtO2Lxky6--e1w@mail.gmail.com \
    --to=rick@support-intelligence.com \
    --cc=bitcoin-development@lists.sourceforge.net \
    --cc=mike@plan99.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox