I am a bit confused about TemplateLibrary. I understand that it is essentially to reuse boiler plate code. What I don't understand is that how does fitnesse decide which pages to include in the dropdown.
If we look at the following :
All those highlighted appear in the dropdown. All that talk about brothers and uncles (may be I don't understand brothers and uncles concept) -
These pages act as a marker to find templates to show as available for insertion when editing a page. All children of a TemplateLibrary will be shown in the drop-down list of templates available for insertion. Unlike the other special pages, all brother and uncle TemplateLibrary pages are included. The oldest (grandest uncle) is included first. The brother, if it exists, is included last. This allows younger TemplateLibrary pages to override older ones
http://www.fitnesse.org/FitNesse.UserGuide.WritingAcceptanceTests.SpecialPages
To cut a long story short - How is it decided which ones are included in the dropdown?
I believe all direct children of a TemplateLibrary are included in the dropdown, as your highlighting also shows.
But there may be multiple pages called TemplateLibrary in a hierarchy of pages. The one you show is at the root of the entire wiki, but you can add others (by adding a page and giving it the special name 'TemplateLibrary').
The talk of brothers and uncles is about which template library pages are relevant on which page in the wiki (similar to how Slim handles ScenarioLibrary pages). In other words: the children of which pages are considered templates.
For instance, given the following hierarchy:
+ TemplateLibrary
++ Template1
+ WebTests
++ HomePageTest
+ SoapTests
++ TemplateLibrary
+++ Template2
++ Service1Tests
+++ TemplateLibrary
++++ Template3
+++ MyService1Test
When you add a page at the root level, or under WebTests then Template1 is available. When you add a page under SoapTests then Template1 and Template2 are available. When you add a page under Service1Tests then Template1, Template2 and Template3 are available.
If the TemplateLibrary under Service1Tests would have a child named Template1 then choosing Template1 for a new page under Service1Tests would use that page and not the one from the root level.
Related
This is related to Site-Catalyst reporting.
I was looking into 'Next Page Flow Report' for a particular page. The report says, for a particular time duration, the total path views were 4500. But when I looked into 'pageViews' report of the same page, it says, the pageViews of that page for the same duration was 5,000. Ideally, the pageViews and path views should match, since anyone who landed on that page (which is pageview) must either exit or should navigate to any next page (which comes in next page flow report). Not sure, why this difference is coming then.
Does anyone has any idea about this ? Please help.
Thanks,
Adwait
For example, let's say you have 3 pages, and lets say that individually (looking at pages report), each page had 10 page views:
PageA : 10 page views
PageB : 10 page views
PageC : 10 page views
In your pages report, you should see it just like that. But page views within a pathing report are shown in relation to paths, not standalone page views. So for example, one path could be:
PageA (3 page views) > PageB (4 page views) > (exited site)
This just shows how many people took the same path throughout your site, where they diverged, etc..think of it like a choose-your-own-adventure book, where at each point of the story, the reader can choose which way the story goes, so that overall, there are different permutations of the story. A website works in much the same way. Visitors can start off on virtually any page accessible on your site (though usually the homepage or landing pages are the most common), and from there, they navigate to wherever else on your site.
So, if you were to add up the page views for PageA for all the paths, it should match what's in the base pages report, but if you are looking at page views for an individual path, it's not going to add up, because it's just page views for that page that happened in that one path (well, it's theoretically possible for them to match, e.g. if there's only one path, but that's highly unlikely to actually happen).
Path Views will always report Pure Page Views (yes, I call it Pure).
What does this mean? Well, it simply means that the Path Views for a Page is equal to the Total Page Views less the Reloads of that Page for a specific period.
Therefore, if your Path Views are 4500, and Page Views are 5000, then this means that your page was reloaded 500 times.
I am new to Specflow and need a way to reuse scenarios in multiple feature files.
I have a web application consisting of multiple pages that each share a many items such as footer content. Say my footer contains 3 links:
Help | Feedback | FAQ
I have a scenario to test the "Help" link functionality:
Scenario: Help link
Given I am on page1
When I click on the link containing text "Help"
Then I see the help popup
As the "Given" statement specifies which page to open, the scenario is tied to that page. In order to test the same help link functionality on page2, page3, page4, etc., I would need to:
1) Copy the scenario into another feature file
2) Change the given statement to reference the correct page
3) Repeat for all pages containing the help link!
This seems like an awful lot of duplication and there must be a better way to do this.
You can use a Scenario Outline, which is basically a data driven test:
Scenario Outline: Help link
Given I am on <Page>
When I click on the link containing text "Help"
Then I see the help popup
Examples:
| Page |
| Home |
| Contact Us |
| About Us |
You can't test everything when you work at this level. In fact you can only test a fraction of whats possible. So what you have to do is think about what benefit you get for testing the footer on each other page, and see if this is worth the cost of
Writing the tests
Running the tests
Secondly you don't need to repeat all the tests for each page. If the links work on one page then they will work on every other page, so you could test the links once, and then subsequently check that the footer appears on other pages e.g.
Feature: Footer checks
Scenario: Footer appears on pages
Given a selection of pages
When each page is visited
Then each page should have the footer
and have your selection of pages be a random small sample from all the pages.
I was wondering if anyone could comment on which way is better and WHY?
Here is a simplified version of what I have ( in HAML):
#header
#root
#content
= yield
#sidebar
= context_navigation
#footer
The problem:
I want #sidebar to display on some pages to show context menu, such as on the account page to show links to profile, password, order history. On the product page show links to product specifications, description, "send link", etc. But not on other pages - such as on the home page I need to use the whole width of #root for #content to show news or featured items.
Solution & Question:
I have several ideas on how to implement it, but I was looking for some input at to which one you think is better and please explain WHY? The main objective is maintainability of code.
Here are some ideas:
CSS \ SCSS trickery - make the sidebar a collapsible div if there context navigation is empty
Use an else/if to load different partials depending on which part of the site I'm in.
Create a separate layout (seems like an overkill - as I understand layouts are to be used mostly for different media such as screen vs. print vs. pdf vs. mobile - etc)
Any other ideas?
Thank you,
Nick
You could use nested layouts to get this working:
http://guides.rubyonrails.org/layouts_and_rendering.html#using-nested-layouts
Different views might serve you well... you may need to rethink your controller also to make them more use case specific. Going along this route will make you app more dynamic, increase cohesion amongst all of the components and allow for greater extensibility.
Does anyone know how to pass Content/ContentPlaceholder information from a page, up through it's master page, to the parent master page?
Like this example, but with content defined in ChildFile (the page), being output in ParentMaster (q matster page one level higher in the nesting).
AFAIK this is not possible. I haven't found a perfect solution to this myself, but usually what works well for a little amount of possibilities (such as a 3-choice navigation bar) is a deriving secondary master pages from the master page and using those in your views. Another solution one is would be using javascript to manipulate the master page's content. A third one would be to isolate the content you want to change from the client page into a separate contentplaceholder and specify that on the client page.
Edit: With the arrival of Razor, this problem is now perfectly solved: Simply put your variables in the ViewBag in the child view and read it in the layout.
Use properties, pass them through and let the main master page decide what to do upon rendering
I have a website that will contain 2 type of layout.
With no columns
With 2 columns
Header, footer and lots of other parts are the same for both, but inside the main content, there 2 separate layouts and I'd like to choose between 2 site masters. How would I go about accomplishing this?
I was thinking about making a main site master and have the one with the 2 column inherit from that. If that is the correct method, what are the keywords to google for, or you are free to explain inheriting site masters here.
Thank you,
Master pages can inside a master page themselves just like any other view. Just specify the master's MasterPageFile directive as usual:
<%# Master Language="C#" MasterPageFile="~/Views/Shared/App.Master"
Inherits="System.Web.Mvc.ViewMasterPage" %>
Your views can choose to use the overall master page or the nested one as their masters.
Alternately, you can set the MasterPage of your views dynamically in several ways. The regular View() method has an overload to specify the master page:
return View("SomePage", "MasterPageFileHere");
or even better would be to specify an action method to do it for you globally. You can see a good walkthrough of that here.