Quantcast

passing hashmap to a fixture

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

passing hashmap to a fixture

atlantavb
Hash tables can be displayed in a wiki table using !{} markup, like
   !{ibm:1,goog:1}
That works great, but I haven't been able to figure out how to pass that info in to a fixture (specifically, a ColumnFixture).  I have tried making the corresponding public member both HashMap and String, neither seems to work (the value of the member ends up as null).  I am able to pass the data as a String array, ibm:1,goog:2 and then splitting each element on :, but that I would prefer to have the tabular display in the wiki.

Any clues?

-Andy

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: passing hashmap to a fixture

Gregor Gramlich
Hi Andy,

I am not 100% sure, but this probably is not supported by the FIT
ColumnFixture.
It works with Slim fixtures and might also work with FitLibrary fixtures,
but Rick can probably tell us.

Gregor


2011/3/8 atlantavb <[hidden email]>

>
>
> Hash tables can be displayed in a wiki table using !{} markup, like
> !{ibm:1,goog:1}
> That works great, but I haven't been able to figure out how to pass that
> info in to a fixture (specifically, a ColumnFixture). I have tried making
> the corresponding public member both HashMap and String, neither seems to
> work (the value of the member ends up as null). I am able to pass the data
> as a String array, ibm:1,goog:2 and then splitting each element on :, but
> that I would prefer to have the tabular display in the wiki.
>
> Any clues?
>
> -Andy
>
>  
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: passing hashmap to a fixture

Rick Mugridge
Hi Andy and Gregor,

On 9/03/2011 9:13 a.m., Gregor Gramlich wrote:
>
> Hi Andy,
>
>
> I am not 100% sure, but this probably is not supported by the FIT
> ColumnFixture.

Not that I know of for Java.
> It works with Slim fixtures and might also work with FitLibrary
> fixtures, but Rick can probably tell us.
No I have not added support for that in FitLibrary in Java, but could do
so. What html is generated?

Cheers, Rick

>
> Gregor
>
>
> 2011/3/8 atlantavb <[hidden email] <mailto:[hidden email]>>
>
>     Hash tables can be displayed in a wiki table using !{} markup, like
>     !{ibm:1,goog:1}
>     That works great, but I haven't been able to figure out how to
>     pass that info in to a fixture (specifically, a ColumnFixture). I
>     have tried making the corresponding public member both HashMap and
>     String, neither seems to work (the value of the member ends up as
>     null). I am able to pass the data as a String array, ibm:1,goog:2
>     and then splitting each element on :, but that I would prefer to
>     have the tabular display in the wiki.
>
>     Any clues?
>
>     -Andy
>
>
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: passing hashmap to a fixture

Gregor Gramlich
Hi Rick,

it is described here under Version 0.1

http://fitnesse.org/FitNesse.UserGuide.SliM.SlimProtocol

It is a simple html table with two columns

http://fitnesse.org/FitNesse.UserGuide.MarkupHashTable

Gregor


2011/3/8 Rick Mugridge <[hidden email]>

>
>
> Hi Andy and Gregor,
>
>
> On 9/03/2011 9:13 a.m., Gregor Gramlich wrote:
>
>
>
> Hi Andy,
>
>  I am not 100% sure, but this probably is not supported by the FIT
> ColumnFixture.
>
>
> Not that I know of for Java.
>
>   It works with Slim fixtures and might also work with FitLibrary
> fixtures, but Rick can probably tell us.
>
> No I have not added support for that in FitLibrary in Java, but could do
> so. What html is generated?
>
> Cheers, Rick
>
>
>  Gregor
>
>
> 2011/3/8 atlantavb <[hidden email]>
>
>>
>>
>> Hash tables can be displayed in a wiki table using !{} markup, like
>> !{ibm:1,goog:1}
>> That works great, but I haven't been able to figure out how to pass that
>> info in to a fixture (specifically, a ColumnFixture). I have tried making
>> the corresponding public member both HashMap and String, neither seems to
>> work (the value of the member ends up as null). I am able to pass the data
>> as a String array, ibm:1,goog:2 and then splitting each element on :, but
>> that I would prefer to have the tabular display in the wiki.
>>
>> Any clues?
>>
>> -Andy
>>
>>
>    
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: passing hashmap to a fixture

Rick Mugridge
I see, thanks Gregor.

FitLibrary already supports any nested table, so it will support that.

So the action:

|''try out hash tables''|!{ibm:1,goog:1}|

with the right fixturing can call into the following method, for example:

public void tryOutHashTables(Map<String,Integer> map) {
   ...
}

Andy: FitLibrary has two alternatives to ColumnFixture that support the
above: CalculateFixture and RuleTable.

Cheers, Rick

On 9/03/2011 9:34 a.m., Gregor Gramlich wrote:

>
> Hi Rick,
>
>
> it is described here under Version 0.1
>
> http://fitnesse.org/FitNesse.UserGuide.SliM.SlimProtocol
>
> It is a simple html table with two columns
>
> http://fitnesse.org/FitNesse.UserGuide.MarkupHashTable
>
> Gregor
>
>
> 2011/3/8 Rick Mugridge <[hidden email]
> <mailto:[hidden email]>>
>
>     Hi Andy and Gregor,
>
>
>
>     On 9/03/2011 9:13 a.m., Gregor Gramlich wrote:
>>
>>     Hi Andy,
>>
>>
>>     I am not 100% sure, but this probably is not supported by the FIT
>>     ColumnFixture.
>
>     Not that I know of for Java.
>
>>     It works with Slim fixtures and might also work with FitLibrary
>>     fixtures, but Rick can probably tell us.
>     No I have not added support for that in FitLibrary in Java, but
>     could do so. What html is generated?
>
>     Cheers, Rick
>
>>
>>     Gregor
>>
>>
>>     2011/3/8 atlantavb <[hidden email] <mailto:[hidden email]>>
>>
>>         Hash tables can be displayed in a wiki table using !{}
>>         markup, like
>>         !{ibm:1,goog:1}
>>         That works great, but I haven't been able to figure out how
>>         to pass that info in to a fixture (specifically, a
>>         ColumnFixture). I have tried making the corresponding public
>>         member both HashMap and String, neither seems to work (the
>>         value of the member ends up as null). I am able to pass the
>>         data as a String array, ibm:1,goog:2 and then splitting each
>>         element on :, but that I would prefer to have the tabular
>>         display in the wiki.
>>
>>         Any clues?
>>
>>         -Andy
>>
>>
>
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: passing hashmap to a fixture

timander37
In reply to this post by atlantavb
Yes, using HashMaps with FitLibrary works great.  Coincidentally, HashMaps look a lot like HttpRequests, which works great for acceptance testing. Here's part of an example from a user groups presentation I gave:

!**> discs for sale
!define discsForSale {
|Archangel|$12|
|Stingray|$14|
|Gazelle|$8|
|Starfire|$11|
|Tee-Bird|$10|
}
**!

|disc shop|
|sells|${discsForSale}|

public boolean sells(Map<String, String> map) {
  Set<String> discNames = map.keySet();
  for (String discName : discNames) {
    Disc disc = new Disc(discName, map.get(discName));
    store.addToInventory(disc);
  }
  return true;
}

For the full example, see https://github.com/timander/fitnesse-intro

Regards,
Tim Andersen


--- In [hidden email], "atlantavb" <andyd100@...> wrote:
>
> Hash tables can be displayed in a wiki table using !{} markup, like
>    !{ibm:1,goog:1}
> That works great, but I haven't been able to figure out how to pass that info in to a fixture (specifically, a ColumnFixture).  I have tried making the corresponding public member both HashMap and String, neither seems to work (the value of the member ends up as null).  I am able to pass the data as a String array, ibm:1,goog:2 and then splitting each element on :, but that I would prefer to have the tabular display in the wiki.
>
> Any clues?
>
> -Andy
>


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Re: passing hashmap to a fixture

Rick Mugridge
Hi Tim,

Yes, as you say, that's the other way to use a hashmap: By using a
nested tables specified with a !define , instead of the !{} markup.

To use the !{} form when the key and the value contain blanks, or ":",
it's necessary to use !defines anyway.

As a note to others: FitLibrary also allows the use of nested tables to
represent lists, sets, arrays, and objects (with property-value pairs),
both for creating them and for checking them.

Tim, Do you make much use of nested tables? I've been thinking about how
to make them easier to edit, by being able to select a cell with a
nested table in it and then be able to edit just that table. Likewise
for selecting a single table for editing when it's in a longer sequence.

Cheers, Rick

On 10/03/2011 3:31 a.m., timander37 wrote:

>
> Yes, using HashMaps with FitLibrary works great. Coincidentally,
> HashMaps look a lot like HttpRequests, which works great for
> acceptance testing. Here's part of an example from a user groups
> presentation I gave:
>
> !**> discs for sale
> !define discsForSale {
> |Archangel|$12|
> |Stingray|$14|
> |Gazelle|$8|
> |Starfire|$11|
> |Tee-Bird|$10|
> }
> **!
>
> |disc shop|
> |sells|${discsForSale}|
>
> public boolean sells(Map<String, String> map) {
> Set<String> discNames = map.keySet();
> for (String discName : discNames) {
> Disc disc = new Disc(discName, map.get(discName));
> store.addToInventory(disc);
> }
> return true;
> }
>
> For the full example, see https://github.com/timander/fitnesse-intro
>
> Regards,
> Tim Andersen
>
> --- In [hidden email] <mailto:fitnesse%40yahoogroups.com>,
> "atlantavb" <andyd100@...> wrote:
> >
> > Hash tables can be displayed in a wiki table using !{} markup, like
> > !{ibm:1,goog:1}
> > That works great, but I haven't been able to figure out how to pass
> that info in to a fixture (specifically, a ColumnFixture). I have
> tried making the corresponding public member both HashMap and String,
> neither seems to work (the value of the member ends up as null). I am
> able to pass the data as a String array, ibm:1,goog:2 and then
> splitting each element on :, but that I would prefer to have the
> tabular display in the wiki.
> >
> > Any clues?
> >
> > -Andy
> >
>
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: passing hashmap to a fixture

timander37
Hi Rick,

We use nested tables a lot. Are you thinking of making a better UI from the browser to edit content? We've spent a lot of time training BA's to do this :)

Would it be a plugin, a separate Javascript library or part of the FitNesse distribution? It might be worth experimenting with.

Tim


--- In [hidden email], Rick Mugridge <rick@...> wrote:

>
> Hi Tim,
>
> Yes, as you say, that's the other way to use a hashmap: By using a
> nested tables specified with a !define , instead of the !{} markup.
>
> To use the !{} form when the key and the value contain blanks, or ":",
> it's necessary to use !defines anyway.
>
> As a note to others: FitLibrary also allows the use of nested tables to
> represent lists, sets, arrays, and objects (with property-value pairs),
> both for creating them and for checking them.
>
> Tim, Do you make much use of nested tables? I've been thinking about how
> to make them easier to edit, by being able to select a cell with a
> nested table in it and then be able to edit just that table. Likewise
> for selecting a single table for editing when it's in a longer sequence.
>
> Cheers, Rick
>
> On 10/03/2011 3:31 a.m., timander37 wrote:
> >
> > Yes, using HashMaps with FitLibrary works great. Coincidentally,
> > HashMaps look a lot like HttpRequests, which works great for
> > acceptance testing. Here's part of an example from a user groups
> > presentation I gave:
> >
> > !**> discs for sale
> > !define discsForSale {
> > |Archangel|$12|
> > |Stingray|$14|
> > |Gazelle|$8|
> > |Starfire|$11|
> > |Tee-Bird|$10|
> > }
> > **!
> >
> > |disc shop|
> > |sells|${discsForSale}|
> >
> > public boolean sells(Map<String, String> map) {
> > Set<String> discNames = map.keySet();
> > for (String discName : discNames) {
> > Disc disc = new Disc(discName, map.get(discName));
> > store.addToInventory(disc);
> > }
> > return true;
> > }
> >
> > For the full example, see https://github.com/timander/fitnesse-intro
> >
> > Regards,
> > Tim Andersen
> >
> > --- In [hidden email] <mailto:fitnesse%40yahoogroups.com>,
> > "atlantavb" <andyd100@> wrote:
> > >
> > > Hash tables can be displayed in a wiki table using !{} markup, like
> > > !{ibm:1,goog:1}
> > > That works great, but I haven't been able to figure out how to pass
> > that info in to a fixture (specifically, a ColumnFixture). I have
> > tried making the corresponding public member both HashMap and String,
> > neither seems to work (the value of the member ends up as null). I am
> > able to pass the data as a String array, ibm:1,goog:2 and then
> > splitting each element on :, but that I would prefer to have the
> > tabular display in the wiki.
> > >
> > > Any clues?
> > >
> > > -Andy
> > >
> >
> >
>


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

ZiBreve; an Abstraction tool

Rick Mugridge
Hi Tim,

I have build my own editor, and am thinking about improvements. This is
part of an open-source tool called ZiBreve (reuse of name) I've been
building fulltime for the last year, with just-past research funding
from the NZ government and support from other sources, including Air New
Zealand. It's written in Scala and uses SWT, with embedded browser(s).
It does not depend on FitNesse code at all; it includes my own
concurrent wiki parser. ZiBreve can be used along with FitNesse, as it
uses the same file structure and etc.

The main emphasis of my work at this point is on refactoring Fit and
FitLibrary-based storytests, and especially for extracting
business-level specifications from lower-level, implementation-specific
storytests. ZiBreve looks for any duplication across storytests and
proposes defined actions with parameters, ordered by the compression
that results. It can also look for duplication across the suite that
matches user-selected tables from a storytest. The user can select any
of the abstractions and have them turned into defined actions to be
revised and used. It also looks for potential call sites for existing
defined actions. The user can OK the changes, to be made automatically.
It's fast, as it makes good use of the table structure. We've run it on
a real suite with 2600 storytests, and it finds useful abstractions in
20 seconds. This makes it feasible to take a large suite and
step-by-step, remove repetition, extract multiple layers, and end up
with a suite that is business-focused, and much cheaper to maintain and
evolve. (You can see, Tim, that my thinking is closely aligned with the
ideas in Gojko's forthcoming book.)

I'm also in the process of adding capability to make it much quicker and
easier to create storytests for existing systems. The aim is to aid in
constructing business-level specifications as a goal of this process. My
idea takes the pros of a record-playback approach without any of the
cons. My initial focus is on web-based apps, with Spider, but the ideas
are general, and can be applied if the implementation-level calls can be
recorded (eg, web services, REST, messaging, and potentially from
structured logs).

I'm also adding support for automatic generation of user-level (and
other) documentation from storytests. This will allow storytests to also
be used as examples in documentation. With web-apps, for example, this
could include screen dumps. Initially, I'm looking at generation to
HTML, but other formats are possible. I'm interested to hear from anyone
who would find this valuable and would like to try this in beta when
it's ready.

Finally, others at the University of Waikato have added support for
checking consistency within a business rule table and automatically
suggesting further examples that may fill "holes". We're interested to
hear from anyone who would find this valuable, and especially with
numeric data, who would like to try this in beta when it's ready.

I've improved the editor enough that I can use it to write articles and
publish them on my website. There's still a lot to be done - ZiBreve is
quite incomplete in areas that don't support the research aims. Eg, it
doesn't display SetUp pages at the top of the html view of a page.  It
doesn't support test execution.  It doesn't support page
renaming/moving/deleting. It doesn't yet support search, spell-checking,
auto-completion, ...

Such capability is secondary at this point, but I'd appreciate help on
these from Scala programmers with strong TDD and functional skills. For
Java developers, this could be the opportunity to learn Scala, an
elegant and concise statically-typed language that runs on the JVM (and
eventually, .net). There is reasonable tool-support for Scala in the
free IntelliJ. There is an excellent book on Scala by Odersky et al. As
Scala inter-operates with Java code, some modular functionality could be
added as plugins written in Java.

If you're interested, Tim, in trying the tool out and giving feedback,
let me know. At this stage, I'm interested in feedback from people with
larger storytest suites (ie, more than 200 storytests).

I am away on holiday soon, and have other things to complete, so won't
be doing much further until the end of the month.

I'm hoping to make the first public release of the tool at the end of
April. I will announce it here on the fitnesse email group.

Cheers, Rick

On 11/03/2011 3:43 a.m., timander37 wrote:

>
> Hi Rick,
>
> We use nested tables a lot. Are you thinking of making a better UI
> from the browser to edit content? We've spent a lot of time training
> BA's to do this :)
>
> Would it be a plugin, a separate Javascript library or part of the
> FitNesse distribution? It might be worth experimenting with.
>
> Tim
>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: ZiBreve; an Abstraction tool

Kim Gräsman-2
Hi Rick,

I'd like to pipe in that this sounds like a really interesting product --
but that maybe the mechanics are even more interesting.

It's like you've skipped writing the "Refactoring" book, and jumped straight
to building IntelliJ.

We're looking to do a transformation like this, but we use Fit on .NET, not
Fitnesse, so the steps and mechanisms for abstraction would probably be more
useful to us.

And I suppose the refactoring recipes might be applicable to other tools not
even in the Fit sphere, depending on their abstraction capabilities.

Thanks for posting!

- Kim

On Fri, Mar 11, 2011 at 00:15, Rick Mugridge <[hidden email]> wrote:

>
>
> Hi Tim,
>
> I have build my own editor, and am thinking about improvements. This is
> part of an open-source tool called ZiBreve (reuse of name) I've been
> building fulltime for the last year, with just-past research funding from
> the NZ government and support from other sources, including Air New Zealand.
> It's written in Scala and uses SWT, with embedded browser(s). It does not
> depend on FitNesse code at all; it includes my own concurrent wiki parser.
> ZiBreve can be used along with FitNesse, as it uses the same file structure
> and etc.
>
> The main emphasis of my work at this point is on refactoring Fit and
> FitLibrary-based storytests, and especially for extracting business-level
> specifications from lower-level, implementation-specific storytests. ZiBreve
> looks for any duplication across storytests and proposes defined actions
> with parameters, ordered by the compression that results. It can also look
> for duplication across the suite that matches user-selected tables from a
> storytest. The user can select any of the abstractions and have them turned
> into defined actions to be revised and used. It also looks for potential
> call sites for existing defined actions. The user can OK the changes, to be
> made automatically. It's fast, as it makes good use of the table structure.
> We've run it on a real suite with 2600 storytests, and it finds useful
> abstractions in 20 seconds. This makes it feasible to take a large suite and
> step-by-step, remove repetition, extract multiple layers, and end up with a
> suite that is business-focused, and much cheaper to maintain and evolve.
> (You can see, Tim, that my thinking is closely aligned with the ideas in
> Gojko's forthcoming book.)
>
> I'm also in the process of adding capability to make it much quicker and
> easier to create storytests for existing systems. The aim is to aid in
> constructing business-level specifications as a goal of this process. My
> idea takes the pros of a record-playback approach without any of the cons.
> My initial focus is on web-based apps, with Spider, but the ideas are
> general, and can be applied if the implementation-level calls can be
> recorded (eg, web services, REST, messaging, and potentially from structured
> logs).
>
> I'm also adding support for automatic generation of user-level (and other)
> documentation from storytests. This will allow storytests to also be used as
> examples in documentation. With web-apps, for example, this could include
> screen dumps. Initially, I'm looking at generation to HTML, but other
> formats are possible. I'm interested to hear from anyone who would find this
> valuable and would like to try this in beta when it's ready.
>
> Finally, others at the University of Waikato have added support for
> checking consistency within a business rule table and automatically
> suggesting further examples that may fill "holes". We're interested to hear
> from anyone who would find this valuable, and especially with numeric data,
> who would like to try this in beta when it's ready.
>
> I've improved the editor enough that I can use it to write articles and
> publish them on my website. There's still a lot to be done - ZiBreve is
> quite incomplete in areas that don't support the research aims. Eg, it
> doesn't display SetUp pages at the top of the html view of a page.  It
> doesn't support test execution.  It doesn't support page
> renaming/moving/deleting. It doesn't yet support search, spell-checking,
> auto-completion, ...
>
> Such capability is secondary at this point, but I'd appreciate help on
> these from Scala programmers with strong TDD and functional skills. For Java
> developers, this could be the opportunity to learn Scala, an elegant and
> concise statically-typed language that runs on the JVM (and eventually,
> .net). There is reasonable tool-support for Scala in the free IntelliJ.
> There is an excellent book on Scala by Odersky et al. As Scala
> inter-operates with Java code, some modular functionality could be added as
> plugins written in Java.
>
> If you're interested, Tim, in trying the tool out and giving feedback, let
> me know. At this stage, I'm interested in feedback from people with larger
> storytest suites (ie, more than 200 storytests).
>
> I am away on holiday soon, and have other things to complete, so won't be
> doing much further until the end of the month.
>
> I'm hoping to make the first public release of the tool at the end of
> April. I will announce it here on the fitnesse email group.
>
> Cheers, Rick
>
> On 11/03/2011 3:43 a.m., timander37 wrote:
>
>
>
> Hi Rick,
>
> We use nested tables a lot. Are you thinking of making a better UI from the
> browser to edit content? We've spent a lot of time training BA's to do this
> :)
>
> Would it be a plugin, a separate Javascript library or part of the FitNesse
> distribution? It might be worth experimenting with.
>
> Tim
>
>
>
>
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: ZiBreve; an Abstraction tool

Rick Mugridge
Hi Kim,

Thanks for your enthusiastic reply.

Yes, the mechanics are interesting; it's been a challenge to make all
this work quickly and effectively.

I will continue with writing the "refactoring" book, as you call it;
I've got several more in the series already worked out. But I've been
busy with other commitments that put bread on the table. As you say, the
refactoring ideas will apply more generally.

The abstraction process in ZiBreve is based purely on tables, so it will
work on any table-based storytests written with FitNesse wiki syntax.
The algorithms I developed depend strongly on the table structure to
provide the speed.

Now ZiBreve generates the text of a defined action from a selected
abstraction, so the user can alter it, provide keywords, parameter
names, and etc. Then the user can ask to find all potential calls of any
or all defined actions, and the user can then action the automatic
changes. This way, you can either have ZiBreve search for repetition or
you can decide on what abstractions you want to introduce and use it to
make it happen.

For storytests that are not for FitLibrary-in-Java, the first stage only
will be useful. Then, you can take the generated defined action and turn
it into fixturing code, or a scenario for Slim or a procedure for
FitSharp. With fixturing code, you can use ZiBreve to apply the changes
as well. However, scenarios and procedures are less general than defined
actions, so only some will apply. In defined actions, the body can
contain multiple tables, and these can be of any type (including Fit
tables).

Initially, refactoring of actions only applies to defined actions, but
it won't take much to apply it to actions that are implemented by
fixtures. I haven't yet considered what refactorings to implement for
other table types -- being able to rename headers in a ColumnFixture or
decision table or similar is an obvious one. I'll consider making
refactorings pluggable.

Cheers, Rick

On 25/03/2011 6:28 p.m., Kim Gräsman wrote:

>
> Hi Rick,
>
>
> I'd like to pipe in that this sounds like a really interesting product
> -- but that maybe the mechanics are even more interesting.
>
> It's like you've skipped writing the "Refactoring" book, and jumped
> straight to building IntelliJ.
>
> We're looking to do a transformation like this, but we use Fit on
> .NET, not Fitnesse, so the steps and mechanisms for abstraction would
> probably be more useful to us.
>
> And I suppose the refactoring recipes might be applicable to other
> tools not even in the Fit sphere, depending on their abstraction
> capabilities.
>
> Thanks for posting!
>
> - Kim
>
> On Fri, Mar 11, 2011 at 00:15, Rick Mugridge <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>
>
>     Hi Tim,
>
>     I have build my own editor, and am thinking about improvements.
>     This is part of an open-source tool called ZiBreve (reuse of name)
>     I've been building fulltime for the last year, with just-past
>     research funding from the NZ government and support from other
>     sources, including Air New Zealand. It's written in Scala and uses
>     SWT, with embedded browser(s). It does not depend on FitNesse code
>     at all; it includes my own concurrent wiki parser. ZiBreve can be
>     used along with FitNesse, as it uses the same file structure and etc.
>
>     The main emphasis of my work at this point is on refactoring Fit
>     and FitLibrary-based storytests, and especially for extracting
>     business-level specifications from lower-level,
>     implementation-specific storytests. ZiBreve looks for any
>     duplication across storytests and proposes defined actions with
>     parameters, ordered by the compression that results. It can also
>     look for duplication across the suite that matches user-selected
>     tables from a storytest. The user can select any of the
>     abstractions and have them turned into defined actions to be
>     revised and used. It also looks for potential call sites for
>     existing defined actions. The user can OK the changes, to be made
>     automatically. It's fast, as it makes good use of the table
>     structure. We've run it on a real suite with 2600 storytests, and
>     it finds useful abstractions in 20 seconds. This makes it feasible
>     to take a large suite and step-by-step, remove repetition, extract
>     multiple layers, and end up with a suite that is business-focused,
>     and much cheaper to maintain and evolve. (You can see, Tim, that
>     my thinking is closely aligned with the ideas in Gojko's
>     forthcoming book.)
>
>     I'm also in the process of adding capability to make it much
>     quicker and easier to create storytests for existing systems. The
>     aim is to aid in constructing business-level specifications as a
>     goal of this process. My idea takes the pros of a record-playback
>     approach without any of the cons. My initial focus is on web-based
>     apps, with Spider, but the ideas are general, and can be applied
>     if the implementation-level calls can be recorded (eg, web
>     services, REST, messaging, and potentially from structured logs).
>
>     I'm also adding support for automatic generation of user-level
>     (and other) documentation from storytests. This will allow
>     storytests to also be used as examples in documentation. With
>     web-apps, for example, this could include screen dumps. Initially,
>     I'm looking at generation to HTML, but other formats are possible.
>     I'm interested to hear from anyone who would find this valuable
>     and would like to try this in beta when it's ready.
>
>     Finally, others at the University of Waikato have added support
>     for checking consistency within a business rule table and
>     automatically suggesting further examples that may fill "holes".
>     We're interested to hear from anyone who would find this valuable,
>     and especially with numeric data, who would like to try this in
>     beta when it's ready.
>
>     I've improved the editor enough that I can use it to write
>     articles and publish them on my website. There's still a lot to be
>     done - ZiBreve is quite incomplete in areas that don't support the
>     research aims. Eg, it doesn't display SetUp pages at the top of
>     the html view of a page.  It doesn't support test execution.  It
>     doesn't support page renaming/moving/deleting. It doesn't yet
>     support search, spell-checking, auto-completion, ...
>
>     Such capability is secondary at this point, but I'd appreciate
>     help on these from Scala programmers with strong TDD and
>     functional skills. For Java developers, this could be the
>     opportunity to learn Scala, an elegant and concise
>     statically-typed language that runs on the JVM (and eventually,
>     .net). There is reasonable tool-support for Scala in the free
>     IntelliJ. There is an excellent book on Scala by Odersky et al. As
>     Scala inter-operates with Java code, some modular functionality
>     could be added as plugins written in Java.
>
>     If you're interested, Tim, in trying the tool out and giving
>     feedback, let me know. At this stage, I'm interested in feedback
>     from people with larger storytest suites (ie, more than 200
>     storytests).
>
>     I am away on holiday soon, and have other things to complete, so
>     won't be doing much further until the end of the month.
>
>     I'm hoping to make the first public release of the tool at the end
>     of April. I will announce it here on the fitnesse email group.
>
>     Cheers, Rick
>
>     On 11/03/2011 3:43 a.m., timander37 wrote:
>>
>>     Hi Rick,
>>
>>     We use nested tables a lot. Are you thinking of making a better
>>     UI from the browser to edit content? We've spent a lot of time
>>     training BA's to do this :)
>>
>>     Would it be a plugin, a separate Javascript library or part of
>>     the FitNesse distribution? It might be worth experimenting with.
>>
>>     Tim
>>
>
>
>
>
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: ZiBreve; an Abstraction tool

Rick Mugridge
BTW, if you use HTML instead of FitNesse, it would be trivial to parse
the HTML into the internal representation of wiki text that I use (an
Abstract Syntax Tree, or AST). The AST already generates HTML (and wiki
text), as you'd expect.

Cheers, Rick

On 26/03/2011 11:21 a.m., Rick Mugridge wrote:

>
> Hi Kim,
>
> Thanks for your enthusiastic reply.
>
> Yes, the mechanics are interesting; it's been a challenge to make all
> this work quickly and effectively.
>
> I will continue with writing the "refactoring" book, as you call it;
> I've got several more in the series already worked out. But I've been
> busy with other commitments that put bread on the table. As you say,
> the refactoring ideas will apply more generally.
>
> The abstraction process in ZiBreve is based purely on tables, so it
> will work on any table-based storytests written with FitNesse wiki
> syntax. The algorithms I developed depend strongly on the table
> structure to provide the speed.
>
> Now ZiBreve generates the text of a defined action from a selected
> abstraction, so the user can alter it, provide keywords, parameter
> names, and etc. Then the user can ask to find all potential calls of
> any or all defined actions, and the user can then action the automatic
> changes. This way, you can either have ZiBreve search for repetition
> or you can decide on what abstractions you want to introduce and use
> it to make it happen.
>
> For storytests that are not for FitLibrary-in-Java, the first stage
> only will be useful. Then, you can take the generated defined action
> and turn it into fixturing code, or a scenario for Slim or a procedure
> for FitSharp. With fixturing code, you can use ZiBreve to apply the
> changes as well. However, scenarios and procedures are less general
> than defined actions, so only some will apply. In defined actions, the
> body can contain multiple tables, and these can be of any type
> (including Fit tables).
>
> Initially, refactoring of actions only applies to defined actions, but
> it won't take much to apply it to actions that are implemented by
> fixtures. I haven't yet considered what refactorings to implement for
> other table types -- being able to rename headers in a ColumnFixture
> or decision table or similar is an obvious one. I'll consider making
> refactorings pluggable.
>
> Cheers, Rick
>
> On 25/03/2011 6:28 p.m., Kim Gräsman wrote:
>
>> Hi Rick,
>>
>>
>> I'd like to pipe in that this sounds like a really interesting
>> product -- but that maybe the mechanics are even more interesting.
>>
>> It's like you've skipped writing the "Refactoring" book, and jumped
>> straight to building IntelliJ.
>>
>> We're looking to do a transformation like this, but we use Fit on
>> .NET, not Fitnesse, so the steps and mechanisms for abstraction would
>> probably be more useful to us.
>>
>> And I suppose the refactoring recipes might be applicable to other
>> tools not even in the Fit sphere, depending on their abstraction
>> capabilities.
>>
>> Thanks for posting!
>>
>> - Kim
>>
>> On Fri, Mar 11, 2011 at 00:15, Rick Mugridge <[hidden email]
>> <mailto:[hidden email]>> wrote:
>>
>>
>>
>>     Hi Tim,
>>
>>     I have build my own editor, and am thinking about improvements.
>>     This is part of an open-source tool called ZiBreve (reuse of
>>     name) I've been building fulltime for the last year, with
>>     just-past research funding from the NZ government and support
>>     from other sources, including Air New Zealand. It's written in
>>     Scala and uses SWT, with embedded browser(s). It does not depend
>>     on FitNesse code at all; it includes my own concurrent wiki
>>     parser. ZiBreve can be used along with FitNesse, as it uses the
>>     same file structure and etc.
>>
>>     The main emphasis of my work at this point is on refactoring Fit
>>     and FitLibrary-based storytests, and especially for extracting
>>     business-level specifications from lower-level,
>>     implementation-specific storytests. ZiBreve looks for any
>>     duplication across storytests and proposes defined actions with
>>     parameters, ordered by the compression that results. It can also
>>     look for duplication across the suite that matches user-selected
>>     tables from a storytest. The user can select any of the
>>     abstractions and have them turned into defined actions to be
>>     revised and used. It also looks for potential call sites for
>>     existing defined actions. The user can OK the changes, to be made
>>     automatically. It's fast, as it makes good use of the table
>>     structure. We've run it on a real suite with 2600 storytests, and
>>     it finds useful abstractions in 20 seconds. This makes it
>>     feasible to take a large suite and step-by-step, remove
>>     repetition, extract multiple layers, and end up with a suite that
>>     is business-focused, and much cheaper to maintain and evolve.
>>     (You can see, Tim, that my thinking is closely aligned with the
>>     ideas in Gojko's forthcoming book.)
>>
>>     I'm also in the process of adding capability to make it much
>>     quicker and easier to create storytests for existing systems. The
>>     aim is to aid in constructing business-level specifications as a
>>     goal of this process. My idea takes the pros of a record-playback
>>     approach without any of the cons. My initial focus is on
>>     web-based apps, with Spider, but the ideas are general, and can
>>     be applied if the implementation-level calls can be recorded (eg,
>>     web services, REST, messaging, and potentially from structured logs).
>>
>>     I'm also adding support for automatic generation of user-level
>>     (and other) documentation from storytests. This will allow
>>     storytests to also be used as examples in documentation. With
>>     web-apps, for example, this could include screen dumps.
>>     Initially, I'm looking at generation to HTML, but other formats
>>     are possible. I'm interested to hear from anyone who would find
>>     this valuable and would like to try this in beta when it's ready.
>>
>>     Finally, others at the University of Waikato have added support
>>     for checking consistency within a business rule table and
>>     automatically suggesting further examples that may fill "holes".
>>     We're interested to hear from anyone who would find this
>>     valuable, and especially with numeric data, who would like to try
>>     this in beta when it's ready.
>>
>>     I've improved the editor enough that I can use it to write
>>     articles and publish them on my website. There's still a lot to
>>     be done - ZiBreve is quite incomplete in areas that don't support
>>     the research aims. Eg, it doesn't display SetUp pages at the top
>>     of the html view of a page.  It doesn't support test execution.
>>     It doesn't support page renaming/moving/deleting. It doesn't yet
>>     support search, spell-checking, auto-completion, ...
>>
>>     Such capability is secondary at this point, but I'd appreciate
>>     help on these from Scala programmers with strong TDD and
>>     functional skills. For Java developers, this could be the
>>     opportunity to learn Scala, an elegant and concise
>>     statically-typed language that runs on the JVM (and eventually,
>>     .net). There is reasonable tool-support for Scala in the free
>>     IntelliJ. There is an excellent book on Scala by Odersky et al.
>>     As Scala inter-operates with Java code, some modular
>>     functionality could be added as plugins written in Java.
>>
>>     If you're interested, Tim, in trying the tool out and giving
>>     feedback, let me know. At this stage, I'm interested in feedback
>>     from people with larger storytest suites (ie, more than 200
>>     storytests).
>>
>>     I am away on holiday soon, and have other things to complete, so
>>     won't be doing much further until the end of the month.
>>
>>     I'm hoping to make the first public release of the tool at the
>>     end of April. I will announce it here on the fitnesse email group.
>>
>>     Cheers, Rick
>>
>>     On 11/03/2011 3:43 a.m., timander37 wrote:
>>>
>>>     Hi Rick,
>>>
>>>     We use nested tables a lot. Are you thinking of making a better
>>>     UI from the browser to edit content? We've spent a lot of time
>>>     training BA's to do this :)
>>>
>>>     Would it be a plugin, a separate Javascript library or part of
>>>     the FitNesse distribution? It might be worth experimenting with.
>>>
>>>     Tim
>>>
>>
>>
>>
>>
>
Loading...