Loading ...
Sorry, an error occurred while loading the content.

Re: [fitnesse] Re: FitLibrary Rule

Expand Messages
  • Mike Stockdale
    Look at CalculateFixture. It s a different take on a decison table layout that might work for you. ... -- Cheers, Mike Stockdale /fit/Sharp
    Message 1 of 5 , Jun 1, 2012
    • 0 Attachment
      Look at CalculateFixture.  It's a different take on a 'decison table' layout that might work for you.

      On 2012-05-31 16:18, Matthew wrote:
       

      Thanks for your reply. I don't have any specific examples that would be easy to follow, but I generally prefer the column-based tests to the story-based tests because of the reduction of cruft.

      I get the intent of the SUT here, but there seems to be an assumption that that the SUT itself requires no separate execution step. For example, if I'm setting a variable number of properties on the SUT for calculation, how can I tell the SUT I'm done setting the properties and to go ahead and crunch the numbers?

      I've found myself forced to make a check to see if the calculation has happened in each and every getter. It's certainly do-able, and not the end of the world, but it's sloppy.

      I've thought about doing just as you suggested, adding an interface for executable rules, but I had stopped short because my last foray into the FitLibrary engine pointed me to a better solution that didn't require any modification at all (which I've found is the case with many things Fitnesse)... I'm just fishing for a better way.

      --- In fitnesse@yahoogroups.com, "Darren Rowley" <rowleydm@...> wrote:
      >
      > The idea with Rule is that each setter really just provides data to your SUT and there shouldn't really be any 'business logic' in the Rule itself. As Rule is just a marker intetface the black magic of row traversal happens else so I don't think it is possible to hook into each rows execution when implementing Rule. It might be possible to extend Rule into a different type (e.g. ExecutableRule) where you provide an execute method but it won't be something that can be done with a couple of lines of code.
      >
      > That said, with FitLbrary there are many ways to skin a cat, and it some cases you don't even need to write fixtures at all. So if you can provide more details on exactly what your trying to achieve, with examples, I might be able to suggest all alternative way.
      >
      > regards,
      > Darren.
      >
      >
      >
      > --- In fitnesse@yahoogroups.com, "Matthew" <msoups@> wrote:
      > >
      > > We're using java/FitLibrary to run our tests. A useful interface for us has been Rule, but I'm bothered by something.
      > >
      > > SLIM has a DecisionTable, which will call all the setters, then an optional execute() method, then all the getters.
      > >
      > > The execute method provides an explicit place to put your execution of business logic. With Rule, it only calls setter and then getters, which forces you to tie in your execution to the getter methods.
      > >
      > > This doesn't feel right. I'm continually surprised by the functionality that has been developed for FitNesse at large, so here's hoping: does FitLibrary have anything similar to decision tables?
      > >
      >


      --
      Cheers,
      Mike Stockdale

      fitSharp
      Syterra Software Inc.
    • Matt Sales
      Hey all, just for future reference (in case you want to play with Rules) I ended up taking a crack at implementing a different type of Rule based on Mike s
      Message 2 of 5 , Jun 11, 2012
      • 0 Attachment

        Hey all, just for future reference (in case you want to play with Rules)

         

        I ended up taking a crack at implementing a different type of Rule based on Mike’s suggestion, but lo and behold, FitLibrary comes to the rescue again.  When examining the code that executes a rule (fitlibrary.traverse.function.RuleTable), I found that FitLibrary actually looks for two optional (undocumented) methods in a Rule implementation:

         

        execute()  

         

        and

         

        reset()

         

         

        execute() will be called after the setters and before the getters.  reset() will be called before the setters.  Thanks again for the replies Mike!

         

         

         

         

         

         

        From: fitnesse@yahoogroups.com [mailto:fitnesse@yahoogroups.com] On Behalf Of Mike Stockdale
        Sent: Friday, June 01, 2012 11:24 AM
        To: fitnesse@yahoogroups.com
        Subject: Re: [fitnesse] Re: FitLibrary Rule

         

         

        Look at CalculateFixture.  It's a different take on a 'decison table' layout that might work for you.

        On 2012-05-31 16:18, Matthew wrote:

         

        Thanks for your reply. I don't have any specific examples that would be easy to follow, but I generally prefer the column-based tests to the story-based tests because of the reduction of cruft.

        I get the intent of the SUT here, but there seems to be an assumption that that the SUT itself requires no separate execution step. For example, if I'm setting a variable number of properties on the SUT for calculation, how can I tell the SUT I'm done setting the properties and to go ahead and crunch the numbers?

        I've found myself forced to make a check to see if the calculation has happened in each and every getter. It's certainly do-able, and not the end of the world, but it's sloppy.

        I've thought about doing just as you suggested, adding an interface for executable rules, but I had stopped short because my last foray into the FitLibrary engine pointed me to a better solution that didn't require any modification at all (which I've found is the case with many things Fitnesse)... I'm just fishing for a better way.

        --- In fitnesse@yahoogroups.com, "Darren Rowley" <rowleydm@...> wrote:
        >
        > The idea with Rule is that each setter really just provides data to your SUT and there shouldn't really be any 'business logic' in the Rule itself. As Rule is just a marker intetface the black magic of row traversal happens else so I don't think it is possible to hook into each rows execution when implementing Rule. It might be possible to extend Rule into a different type (e.g. ExecutableRule) where you provide an execute method but it won't be something that can be done with a couple of lines of code.
        >
        > That said, with FitLbrary there are many ways to skin a cat, and it some cases you don't even need to write fixtures at all. So if you can provide more details on exactly what your trying to achieve, with examples, I might be able to suggest all alternative way.
        >
        > regards,
        > Darren.
        >
        >
        >
        > --- In fitnesse@yahoogroups.com, "Matthew" <msoups@> wrote:
        > >
        > > We're using java/FitLibrary to run our tests. A useful interface for us has been Rule, but I'm bothered by something.
        > >
        > > SLIM has a DecisionTable, which will call all the setters, then an optional execute() method, then all the getters.
        > >
        > > The execute method provides an explicit place to put your execution of business logic. With Rule, it only calls setter and then getters, which forces you to tie in your execution to the getter methods.
        > >
        > > This doesn't feel right. I'm continually surprised by the functionality that has been developed for FitNesse at large, so here's hoping: does FitLibrary have anything similar to decision tables?
        > >
        >

         

        --
        Cheers,
        Mike Stockdale

        fitSharp
        Syterra Software Inc.

      Your message has been successfully submitted and would be delivered to recipients shortly.