Re: [linux-distros-dev] 0.2 + agile development

[Andrew Overholt <overholt@xxxxxxxxxx>]

Hi Ketan,

On Fri, 2009-03-06 at 15:46 +0530, Ketan Padegaonkar wrote:
> Great to hear this initiative. Although I'm not part of the linux-tools, 
> I'd like to offer some help and (free advice)

Thanks!

> Some tools that may help:
>   - MoreUnit[1] (Jump between tests, and code)

Some of us have been using this but we should write up some docs or
something that pertain to our particular case.

>   - hamcrest allows writing DSL'ish tests (available in orbit)

I've never played with hamcrest but I'll give it a shot, thanks.

>   - mocking frameworks, to mock out interfaces and test if listeners are 
> invoked among other things (I recommend mockito[4])

EasyMock is in Orbit, right?  We often find that we get hung up writing
tests because our tools are interacting with native tools that aren't
necessarily on build.eclipse.org but *are* on the developer's box and
thus it's too easy to just Runtime.exec them.  Mocking up output of
these tools would help a lot.  In fact, I have an example:

Utils.runCommandToString("rpm", "-q", pkgName, "--qf", \
  getformattedRpmInformations());

What's the best way to be testing that we're getting the correct output
of rpm -q?  I guess we have to assume that rpm itself is functioning
correctly (and handle errors) and pretend we got the information from
the command?  Perhaps this is an area we need to refactor if it's not
easy to drop in a mock object?

>   - cobertura/eclemma for coverage reports [3]

Some of us have been using Eclemma on our local machines.  I want to get
emma integrated into the common builder at eclipse.org so we can see the
results in hudson.  Would this be of interest to you at all?

> Ensuring that builds are reproducible, developers should be able to do a 
> checkout and build in less 3 steps[2] (or less):

Yeah, I need to write up a doc on how to do our builds as we're using
the Dash common builder.  Once we have our EclipseCon tutorial closer to
finished I'll write up how to do it for our particular case.  It's quite
simple, actually.

> This helps contributors and committers to run the build via ant every 
> time before checking in.

Yup.

Thanks again,

Andrew