I read somewhere that if I start a table with |script| on a line by itself, without specifying a fixture name, FitNesse / Slim will reuse the fixture from the previous script table:
|script|my script table fixture|
|check|do something|ok|
Then something else happens, but later I want to keep using that fixture:
|script|
|check|do something else|ok|
But now I can't find where this is documented. It's not mentioned on the documentation page for script tables. Where is this feature actually described?
It is on the page you linked, although not too clearly:
If there is no actor specified then the previous script table's actor on this test page will be used.
Related
I have been given the task of creating a DXL script. First problem is that I have never used DXL before, even though I have many years experience with DOORS itself. I have been surfing the Net to seek guidance on my particular problem. I also have a few specimen DXL scripts for reference.
My new client requires that for each View of a given Module, of which there are many Views, new "reduced" Modules are to be produced reflecting each View.
By "reduced", I mean that these new Modules are to contain nothing that isn't actually needed for that View., i.e. Columns, Attributes etc. These new Modules will only have the single View.
So, the way forward as I see it, is to take copies of the single master Module, one for each View, rename those copies to reflect a given Master Module/Required View, select that required View in the given copy Module and then delete everything that is not needed by that View, i.e. available Columns, Attributes etc.
This would be simple if I had the required DXL knowledge, which I am endeavouring to pick up as fast as I can.
If at all possible, this script has to be generic and be able to work upon any of the master Module copies to produce the associated "reduced" Module reflecting a particular View.
The client aims to use the script periodically for View archiving (I know, that's the way they want it).
Clarification
Some clarification of what I believe is required, given the following text from my original question:
If at all possible, this script has to be generic and be able to work upon any of the master Module copies to produce the associated "reduced" Module reflecting a particular View.
So, say there are ten views of the master Module, outside of the DXL script, I would copy the master Module ten times, renaming each copy to reflect each of the ten views. Unless you know different, each of those ten copies will reflect the same “Absolute Number”s as are in the master Module, so no problem there?
So, starting with the first of the copied Modules, each named to reflect the View it will eventually represent, its View would be set from the ten Views available to it, that which matches its title.
The single generic DXL script would then be run against that first copy Module, the aim being to delete everything not actually needed for that view, i.e. Attributes, Columns etc. Would some kind of purging command be required in the script for any aforementioned deleted items?
The single generic DXL script would then delete ALL views from that copy Module. The log that is produced when running the script also needs capturing, but I’m not sure whether this should be done from within the script, if possible or as a separate manual task outside of the script.
The aforementioned (indented) process would then be repeated, using the same generic script, against the remaining nine copied Modules. The intension is to leave us with ten copy Modules, each one reflecting one of the ten possible Views, with each one containing only the Attributes, Columns etc. required for that View.
Creating a mirror of a module with this approach is not so easy IMO. Think e.g. about "Absolute Number". If the original module contains the numbers 15 (level 1), 2000 (level 2), 1 (level 1), you will have to create 2000 objects, purge 1997 of them and move them to the correct place.
There is a "duplicate" tool at https://www.ibm.com/developerworks/community/forums/html/topic?id=43862118-113d-4eac-b3f1-21d3b73959d1 which tries to do this, but as stated there, this script is said not to work correctly in all situations.
So, I would rather use the approach "string clipCopy (Item i); string clipPaste(Folder folderRef)". Should be faster and less error prone. But: all Out-Links will also be copied with this method, you will probably have to delete these after the copy or else the link target module(s) will have lots of In-Links.
The problem is still not so easy to solve, as every view might have DXL columns that rely on some or other attribute, and it might contain DXL attributes which again might rely on sth else. I doubt that there is a way to analyze DXL code "on the fly" and find out which columns may be deleted.
Perhaps a totally different approach would be feasible: open each view and create an export to Excel, this way you will get rid of any dynamic dependencies. Then re-import the excel sheet to a new DOORS module. You will still have the "Absolute Number" problem, but perhaps you can make a deal that you will have a pseudo attribute "Original Absolute Number" and disregard the "new" "Absolute Number"'
Quite a big task for a DXL beginner....
Update: On second thought, perhaps you might want to combine these approaches
agree with your employer that you will use an alternative attribute for Absolute Number
use a loop like Russel suggested, when creating objects remember that objects might have to be created "below" or "after" its predecessor or sibling
for DXL attributes do not copy the DXL code but the actual current value of the object
for DXL columns create pseudo attributes _ and create a new view that uses these pseudo attributes instead of the original value
Copying the entire module, then deleting everything not in that view, seems worse than just copying the things you need from each particular view.
I would take the following as the outline of your program:
for view in main module do {
for column in view do {
Find attribute for each column and store (possibly in a skip list?)
Store name of column
}
create new module
create needed types / attributes in new module
create new view in new module
for object in main module {
create object in new module
for attribute in main module {
check if attribute is in new module {
copy info from old object to new
}
}
}
}
Each of these for X in y loops should be in the DXL reference manual in some for or another.
If you need more help, let me know!
Can we use both table template and Freemarker template from hsac-fitnesse-fixtures in the same FitNesse wiki table?
A scenario is not the same as a table template even tho they behave similar.
A Freemarker template is a file template that can be used with variables to create json or XML or other files you need in your test. This is in no way similar to table templates.
To start a different fixture from the one you started the script table, use the start command instead of script.
Example:
|script|fixture|
|do|stuff|
|start|otherfixture|
|do|more|stuff|
So to answer your question, you can use all this in one table.
How to use a scenario vs how to use a table template is another question I am afraid.
I'm using:
Rails 3.2x
Spree 1.2
Ruby 1.9.3x
I'm trying to edit the title of one of my pages, and I cannot find where it is getting defined. It is showing up in my base ERB file as 'title', but that name is sufficiently generic to make it next to impossible to find where it is defined.
I have prodded everywhere I can think, I've tried searching for "title =", but nothing is working. I tried calling source_location on it, but that appears to only work on methods.
Any tricks for finding where a variable is defined?
I can't think of an elegant way. A dumb-but-probably-effective way would be to dump stack trace in your erb, then see what those locations are doing and if title is defined there. It has to enter somewhere between the start of program and invoking your erb.
When I can't find something, I use grep -ri some_string . at the command-line to recursively search all the content of the directory.
It's also a good tactic to let your editor search all the source code, since the ones worth using have the ability to search through all files in a directory.
it is created from a mixture of product names, a site config, and something else
An alternate trick is to add a HTML-comment section in your ERB file, and put the pertinent information for the components used to create the title into that section. Then, let the pages be generated and look inside the page's content to determine what table and row ID it is, the site_config filename, etc.
You really should be able to figure it out based on the parts that are concatenated to build the title and then search your database or files. That information isn't magically created out of thin air by Rails; Someone had to tell Rails how to define the title. But, people move on, or they don't document correctly, so try the embedded information trick.
I was trying to use fixtures plugin for initial (seed)data loading.. the documentation seems very short.. can anyone give some details about
1. where to define all the data, and in which order
2. how to give complex data type (joda time, currency etc)
3. how to load the fixure data only once for the initial data
thanks,
Grails Fixtures plugin documentation is now quite ok, check it here
After installing the plugin you will have a new folder in your Grails App directory called "fixtures". There you may store *.groovy files with the given test data written in the documented DSL.
Example init.groovy file:
// Import needed classes
// Defining some initial testdata
fixture {
cat0(Category, name: "My category 1")
cat1(Category, name: "My category 2")
}
The fixture definitions have to be in the fixture closure.
Edit
Even though the original link to the documentation is not online anymore, the content can still be found in its repository.
I its default configuration fitnesse automatically adds the Test property to all pages ending in "Test".
However, in the project I'm working I have to add the Test property to all pages ending in "Tests". Unfortunately, renaming all pages so that they end in "Test" is not a option for me.
Since the 2008xxxx versions of Fitnesse any page that starts or ends with Test is automatically set to be a test page and any page starting or ending in Suite is set to be a suite. This is done on the creation of the page and probably will not work by just renaming the page.
Note: If you have a large number of test pages to retrofit, you could use wingrep/grepwin (or some other tool that can do large scale file search and replace, I personally use grepwin) and manipulate the properties.xml by inserting
<Test>true</Test>
Set the pages test property in one of the following ways:
1. Visit the page, click properties, select the test checkbox.
2. Vist the page with ?properties, select the test checkbox
3. Modify the properties.xml file associated with the page to include the tag inside the block.
Method 3 would be the easiest to automate for a large number of files.
Could probably do this with a grep file utility to do a mass search and replace.
Or a script (powershell) or program to read the files and add this tag if needed.