StoryQ extensibility

Mar 31, 2010 at 8:46 PM


I was wondering if is it possible to extend StoryQ API with extensions methods?

I inspected StoryQ source code and found that one of possible extensibility points would be the Step class.

In thought that I would create new class ExtendedStep iheriting from Step class, override Execute method and add some extension methods for Condition or Operation classes so that I could inject there instance of ExtendedStep.

Unfortunately it turned out to be impossible.

The only constructor in Step class is marked as internal what effectively prevents inheriting from the Step class (valid Step instance can not be constructed).

Furthermore Execute method is non virtual so it can not be overriden.

Would it be possible to introduce at least mentioned above fixes in next release and make StoryQ extendable?



Apr 1, 2010 at 6:29 AM

Hi Woro

This was intentional, but maybe I didn't understand what StoryQ users would want to do back when I made that decision...

In what way do you want to extend StoryQ? 

Regards - Rob

Apr 1, 2010 at 7:45 PM

I was thinking about handling dynamic arguments in method name formatting (converting method name to string while executing scenario instead of doing it before execution with dynamic scenario based arguments)

I noticed that this issue was discussed in another thread but I thought that I would be able to get such a behavior by simply extending existing framework on my own.

Any framework developer cannot predict all the ways of how his framework would be used ;)

I think that making framework extendable (making classes inheritable and methods overridable) could be with benefit for future of StoryQ development.



Apr 1, 2010 at 10:09 PM

Hi Woro.

For what you are trying to do, I think you'd have a much easier time just editing the source code. The reason I don't want to make everything public and virtual is that as a USER of StoryQ, there is a small subset of classes that you need to care about. It's very different for people EXTENDING storyQ, but one of the reasons we moved to Mercurial (there's a great tutorial at btw) was to make it much easier for people to create custom builds.

You can have Codeplex host your cloned (aka forked) repository (see, which will be public, or you can just keep your repository to yourself, on your own workstation or server. The important thing is, that either way, you'll find it really easy to modify our code, but still pull in new features.

Cheers - Rob


Apr 21, 2010 at 8:00 AM

I have in fact made these public, and shifted them into the "infrastructure" namespace in the following changeset: