incubator-bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Koželj <pe...@digiverse.si>
Subject Re: Tests and CI (was: A word on Release 2)
Date Wed, 10 Oct 2012 08:27:19 GMT
This my get a bit off topic...

I agree that testing is important, and we probably agree that testing is
hard.
In fact a good comprehensive test of a feature can take more effort to
write and maintain that the actual code that implements that feature. So if
plugins do not provide it's own tests and we need to write and maintain the
tests for them, the benefit of using them get's smaller.

And if I dare to get a bit more of topic, I still need to come to terms
with the idea that such a core functionality as ticket relations or multi
products needs to be a plugin or even worse an external plugin! With all
the features I would like to see in a issue tracker, I just can not imagine
how this will work without complex inter-plugin dependencies,
extremely cooperational plugin authors and last but no least, all the time
in the world :)

Peter

On Wed, Oct 10, 2012 at 7:26 AM, Ryan Ollos <ryan.ollos@wandisco.com> wrote:

> On Tue, Oct 9, 2012 at 8:16 PM, Olemis Lang <olemis@gmail.com> 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. :)
>

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