launchpad-dev team mailing list archive

[Jonathan Lange <jml@xxxxxxxxx>]

On Fri, Apr 13, 2012 at 9:18 PM, Graham Binns <graham@xxxxxxxxxxxxx> wrote:
> On 13 April 2012 16:37, Jonathan Lange <jml@xxxxxxxxx> wrote:
>>
>> I'd rather raise ideas here in case because they probably need refinement:
>>
>>  * reduce test suite run time without reducing coverage
>
> We (~Yellow) are working on that - or at least on spreading out the
> load. There are some roadblocks in our way yet, but we're making good
> progress.
>

And that work is much appreciated. I've been devoting a sizeable chunk
of my work hours to removing the road blocks that I can.

I suspect that there might be some opportunities to do this in other
ways. Find tests that are intended to be unit tests but are executing
as integration tests and refactor them to be actual unit tests.

>>  * improve test suite coverage (I assume this bypasses LoC restrictions?)
>>  * something about making tests more focused
>
> I'd be tempted to say something here about death to sample data (since
> it's causing us problems in parallel testing scenarios), too. Maybe
> even death to doctests-that-shouldn't-be-doctests.
>

Yeah, agreed. I'd argue that until LP has some idea of how to present
and navigate its docs, and for whom the docs are written, that all
doctests fall into that category.

>> I'd add something about improving Launchpad's developer documentation,
>> but to be honest, I think it needs something radical to happen to it
>> before mere additions count as improvements.
>
> Laura and I have been talking about something in this area over the
> last couple of days. I'll be giving a talk at UDS with the aim of
> getting people to contribute to Launchpad, and the biggest, most
> important thing we can do right now is make it obvious how to get from
> itch to scratch-committed, which we don't at the moment. It definitely
> needs a massive overhaul.
>

I'm very excited that you & Laura are looking into this!  I wrote the
README and set up launchpad.rtfd.org as abortive attempts toward this,
but it really needs serious, prolonged attention, not just dabbling.

jml