bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan Ollos <>
Subject Re: Tests and CI (was: A word on Release 2)
Date Wed, 10 Oct 2012 05:26:57 GMT
On Tue, Oct 9, 2012 at 8:16 PM, Olemis Lang <> wrote:

> [...]
> What do you mean exactly ? Something like using Gherkin (e.g. Lettuce)
> to describe user stories ?

That's not what I had in mind, but I have a general idea of what you are
talking about and also think that is a good idea to pursue at some point.
I'm thinking, if we are going to use Trac plugins in Bloodhound, then those
plugins need to be tested. One way to go about this is - we install and
manually test them, decide they are good enough and bundle them into the
application. Then, when there is a new version we want that fixes a defect,
we code review the changes, pull in the new version and do all the manual
testing again. Or, we write some functional tests when the plugin is
included in Bloodhound the first time, so that we gain confidence that
whatever we are pulling in doesn't introduce regressions. Some manual
testing still needs to be done of course, but it would be nice to at least
have some minimal automated functional tests ... or at least the framework
in place to develop them at the appropriate time, which is why I raised the
question about the framework. If I'm going to propose that we include a
plugin in Bloodhound and I have a framework to use, I'll write some
functional tests. You can hold me to that ;)

That is for a little later though. The reason I'm raising the issue at this
moment, is that I was fixing some defects in MasterTicketsPlugin, and I'd
like to write some functional tests as part of that process. Probably the
best thing to do right now, since this is outside of Bloodhound still, is
to utilize Twill support in Trac, as you suggest.

> [...]
> Well , it's not quite a big deal for the time being . IMO the first /
> cheapeast step towards testing + CI is to run Trac test suite with
> Bloodhound patches applied .

+1, for making this the first step.

> [...]
> If you mention that after reviewing Trac tests , yes ... Trac
> unitest-style is a PITA ... that's why I wrote my own framework in the
> end
> ;)

Well, I mention after having written some tests when submitting patches to
the Trac core. I guess it wasn't all that bad, but I suspect there is
framework that allows more concise and readable tests. I'm not discounting
your way of doing it because I haven't taken a close look at what you've
done with Twill yet, but I think it is worth getting several opinions and
trying some different options early on, because it is setting the stage for
a lot of work that will go into Bloodhound.

Thanks for the links. I'll read-up and follow-up here. :)

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message