Bzr development stopped

[Martin Pool]

On 14 September 2012 04:55, Brian de Alwis <briandealwis at gmail.com> wrote:
> On 12-Sep-2012, at 11:29 AM, Toshio Kuratomi wrote:
>> Writing test cases, as he points out, are one of the
>>  areas with a learning curve.
>
> FWIW: the run_bzr and run_script style of tests are really easy to set up.  And I'm a total Python n00b. For example:
>
>     def test_tiplog_limit(self):
>         tree = self.make_branch_and_tree('.')
>         tree.commit('message1', rev_id='rev-id')
>
>         self.run_script("""
> $ bzr tiplog --date-format=X --limit 1 --show-ids
> X tip:0 rev-id jrandom at example.com [commit] message1
> """)
>
> Neil's bzr-colo tests were handy references.

This is a really interesting point.  I think we were right to
generally want to have tests for all changes, considering the
importance of bzr being reliable, but it was also a barrier to people
getting their first change in.

It's not so hard to add integration-type tests now: Vincent and I did
want to make it so that people who could just demonstrate the bug on
the command line could also write a test for it, and I'm glad you feel
we succeeded.  On the other hand, shell-like tests are a reasonably
recent addition (2010?).

Even now the initialization of state for the tests is not as
straightforward as I would like.

There was some feeling that just having an integration test is ugly
and bad for code health.  I see the point but you have to consider the
costs; for beginning patches I would rather have an integration test
than no fix or no test.  Perhaps in part this was a reaction to very
early bzr having far too many integration tests (I think there's still
an ugly_tests module.)

Once we added the patch pilot process (2008?), part of that was that
the pilot would if necessary write the tests to get the fix landed.
Sometimes even the experienced pilots found it hard to write those
tests and they didn't always get around to it promptly.

-- 
Martin