I'm wondering is there is a way to use multiple kinds of tables with SLIM (as opposed to FIT) in one test and keeping the context of the same instance of the test class (the harness around the system under test).
With FIT you can enter flow mode by referencing a DoFixture be itself at the start of a test page. This allows you to leverage a variety of different table/fixture type.
I would like to do something similar with SLIM (maybe using a Script Fixture).
Is this possible?
You can have multiple script tables all using the same instance (or 'actor') by not specifying a class as second cell value in the 2nd and following tables, see http://fitnesse.org/FitNesse.UserGuide.WritingAcceptanceTests.SliM.ScriptTable. You can also use this same instance/actor in decision tables (that do not link to separate code, but just invoke scenario's for the activated script fixture, see http://fitnesse.org/FitNesse.UserGuide.WritingAcceptanceTests.SliM.ScenarioTable).
I'm not aware of other Slim tables that can also share a fixture instance.
Related
I'm looking for the best way to solve a problem.
At this moment I have a site for a customer, example.domain.com
My customer ask to create another website with some changes in design, but the contents are the same of the first website. I don't want to duplicate the website, because every feature I add to the site A must be deployed also to site B, and I'm looking a smart way to handle the situation.
I need to keep two different domains and I need also custom mailers and other small tweaks in the controllers (and maybe in some models).
My idea is to put in application controller a before filter like this
before_action :detect_domain
private
def detect_domain
case request.env['HTTP_HOST']
when "example.domain.com"
request.variant = :host1
when "example1.domain.com"
request.variant = :host2
end
end
Then I use the variant with some conditional to choose the mailer, to customize the views and to apply some code changes.
Any other idea?
Using a before filter and a per-request variable like your proposal will work, with a couple caveats that I'll mention below. I'd recommend a tool like the request_store gem to actually store the per-request value of which "skin" is selected.
Now, for the caveats. First, the main problem with per-request variables is that your Rails app does not always exist in the context of a request. Background jobs and console sessions operate outside of the usual request/response flow of your app. You will need to think about what happens when your models or other non-controller/view code is executed when that variable isn't set. I would suggest simply not having your models depend on RequestStore at all -- have the controllers pass any request-specific information down into the models, if needed.
Secondly, it's not clear from your description if you want any data or logical separation between the two domains, or if you just want different look-and-feels. If the former, you might consider the apartment gem, which aims to make database multi-tenancy easier.
EDIT: I also want to mention that, as an alternative to the multi-tenant solution above, you also have the option of a multi-instance solution. Wherein, you use an environment variable to indicate which version of the site should be displayed, and spin up multiple instances of your app (either on the same server with a reverse proxy, or on separate servers with separate DNS entries or a reverse proxy). The downside is increased infrastructure costs, but the context problem I mentioned above no longer exists (everything always has access to environment variables).
I want to create fake usage of my app, as a tutorial.
In order to do so, I need to create fake data (with the same structure and association in real data) to send to my templates, so it renders the same view when my users will have when using the app.
But unfortunately, I didn't find an easy way to do that, except hard coding the examples (fake usage) as a separate view, that looks like the generated view with true data. But this is not useful when you have to change the template, one day or another.
And, mixing true data with fake ones in the database (and then retrieving only fake data when needed) doesn't seem to be a good idea.
Do you have an idea or a gem to suggest?
One option to consider is to use a factory gem (such as factory_girl) or similar (I personally like machinist) and then create some form of script that initializes objects in the test environment.
This may not be the intended or ideal use for a test environment, but you'd be able to utilize your app in a non-production environment with fake data, and allows you to keep data separate from real and/or development data.
The only "gotcha" I can think of is that you'll want to ensure that any automatic testing gem (such as rspec) drops the test database before your tests run. If you don't, you could see errors in your tests due to data already existing in the database.
I've been leaning some of RoR, and when I got to TDD, stuff started to get more complicated. At some point of my App, I thought it would be better to run my tests over the real data.
Real Data vs Sample Data
Searching the web, I found that tests were not meant to run over real data, but over sample data. But yet I couldn't agree with that.
Let's supose my app had an Alias System. So when you access a random url it figures out what that fragment wants and redirects to the proper canonical url. And let's add that an alias dictionary is stored in some models. How would we test agains that dictionary? Hard code spec files for every alias/keyword?
Sticking with real data
The first two things I've realized, yet very unsurely, is:
Rspec testing environment wouldn't access development model's data.
FactoryGirl rules over my testing database, so it's not my option to populate it.
The best solution I could figure out, as the complete newbie I am, is that I could create some classes in spec/support folder and call them inside my factories so as to get that real data. Those classes have a short sample of my real database info, nested, and so my test can go 'real'.
What can pros around suggest to improve it?
I think you may want to look into building a seeds.rb file to populate your databases. This is usually used to initialize the development database so it can be used in your app (and queried in the rails console), but you can use it to seed your test database as described in this answer.
You certainly should not use your development database for testing. You can either seed the test database, or create factories that reflect various scenarios.
FactoryGirl rules over my testing database, so it's not my option to populate it.
You can use more than one factory to represent a business entity, depending on the scenario under test. FactoryGirl makes this easy by allowing you to nest factories. You can define a factory with a basic set of valid attributes and use that in unit tests. For integration (feature) tests, you can use a nested factory that expands on the basic attributes to implement a particular scenario. You can have as many variations of these implementation-specific factories as you need.
So I'm writing my app doing feature-first BDD with Rails, Cucumber, RSpec.
My client requested that a total gets calculated as you fill in the fields.
My question is, this is not really a feature, more of a spec. This is related to the feature of creating the invoice, but I don't think it justifies a whole integration test.
It's just javascript that's running.
So my mind is telling me to write a spec for this in the view spec. Is this correct? And is it possible to test these javascript cases in rspec?
Or should I isolate this a step further and go straight for a javascript testing framework?
I'd really recommend you start with integration tests for every feature you plan to add to your app, they're an invaluable tool for understanding the problem your trying to solve and communicating new additions to the software with clients.
To test JavaScript on your page, you may want to look into Selenium, from memory you can use Selenium as a drop in replacement of Rack::Test when using Capybara to test web pages.
As far as Cucumber goes, I'd suggest making a new feature file for creating the invoice and having a scenario that tests that the correct total total gets calculated when you enter a certain string into a field. Something like:
Scenario: Filling out the form
Given I am looking at the invoice form
When I fill in the fields with <value1> and <value2> without submitting
Then I should see <total> on the page
Obviously I don't know enough about your form to know what fields need to be filled out, but that's a general outline of how I'd test it. I'd also make a test in the view spec to ensure that there is a section for the calculated total value in the form.
After that, I'd drop down to writing specs for the Javascript in Jasmine and implement the code to calculate and display the total.
If you're just trying to test your JavaScript code, I recommend Jasmine.
I have been looking for very basic keyword driven test..i do not understand well how you can separate the test specifically from application so its reusable. In my understanding, the QTP commands like "navigate" are keywords. But how to create my own independent ones? I would be very grateful for example of how to do that. I found either too complex or just theoretical ones.
Thank you very much
In QTP jargon a keyword is a combination of a test object and method (see the available keywords pane).
Keyword driven testing is used to mean creating a test without recording. You can create test objects in one of the following methods and then construct a test from these test objects.
Descriptive programming
Manually create test objects in the object repository (using the create new command)
Using navigate and learn
Record and discard the script
Import from XML
Example of a test.
Go to a web store. Search for a product. Login. Buy. Logout.
(The test is already broken down to keywords)
The simplest approach.
Simply write a list of operations for the corresponding objects. E.g. a simplified variant:
Browser.Open(WebStoreURL)
Browser.Sync
Browser.Page.WebEdit(SearchBoxName).Type "something I want"
' then login, buy, logout using the same approach
' add verification points where needed
In the end you have quite a long script.
If you need to write another script that tests a similar case, you need to repeat most of the actions above.
Another approach.
To avoid duplication, you can, for example, create such functions/actions: Login, Logout, Search(product_name), etc. And then create scripts using these actions/functions, i.e. keywords:
Login
Search "something I want"
Buy
Logout
It is an example of a keyword driven approach. It works on a higher level of abstraction then QTP commands.
The approach is not limited to using QTP functions. Keywords can be implemented as words in an Excel file.
I don't know about overloading of keywords. But when i was writing test cases in QTP for automation. I used configurable navigation paths in the prop or config file n all i needed to do was call a generic function which took source n destination n using those prop files navigate to the proper location.