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.
Related
All I want is a simple script to update some db tables.
My first try was with create-script. These scripts seem not be able to load domain classes. Then I found people saying, you have to create a command.
But in order to create a command you need to create a plugin.
This seems not very straight forward to a have a simple dbupdate script.
Can somebody enlighten me on this.
Thanks
Torsten
Alright! Looks like it is more related to how perform certain db related operations which are not straight forward db-migrations.
Though there could be enormous choices around it, I would like to discuss what could commonly be used:
Groovy Shell: You could create a straight forward groovy shell for your grails project and there run a script you created. No matter it is for some data update or some migration or just a report etc.
The basic idea is to have a command line available to run scripts that perform certain task. This link should help more.
DBMigration: Though in comment you already said it's not a dbmigration,I think your definition of dbmigration is restricted to schema related operations only. That's not true! DBmigration includes schema + CRUD(including a complicated version with join etc as well). We don't prefer crud operations as part of dbmigration as it could be achieved during bootstrap time or using a service method or even some external query or tool.
Like you perform any operation using your application, you could perform this action too. Suppose, you have to perform some updates and inserts in a table. Simply create a service and a controller which access this service to perform desired results. I know this makes least sense, but overall idea is to have a code which could perform desired action.
Well! I would suggest go ahead with first option and create a new shell project pointing to same database. Perform the action there.
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.
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.
For example if I write Add A customer feature which might go like this:
Scenario: Add A customer
Given I am on the customer page
When I enter login name
then I press Add
And I should see the newly added customer confirmation message
I start to write the code in watin to open the browser and go to the customer page.
Which doesn't exist at this point.
The questions are:
1) do I then jump into unit tests and write a unit test for the page that doesn't exist? in MVC this would be a controller but in asp.net webforms it's the same test that is in the step definition.
2) How does the unit test tie in with the step definition? Let's say at the end of the project I have a load of features and a load of unit tests. Then one of the features starts failing if I looked at that how would I know which unit tests correspond to it? Or does this even matter?
I'm not sure if this is a best practice question or it's whatever people feel is right.
Thanks in advance.
One of the cool things about specflow (and cucumber...) is that you can write the test before any page exists. So what I'd do is exactly what you planned to do.
1) Write a specflow test, which describes how you want to work with the page. Looks like you have that already.
2) Run the test. The first line will fail (Given I am on the customer page).
Now you have a choice. Do you just wan to write the code that fires up watin and navigates to the customer page? Fine, do that; then write the customer page (just enough so that the first line of the test passes).
Or, recognize that your test requires a customer page. There's lots here to test: do all the data fields exist? Does the page do input validation correctly? If I post to the server, do I get the correct response? If I post to the server, does the DB get updated correctly? And so on. Some of these sound like unit tests (business logic that takes the form data and stores it in the DB); some sound like UI tests that would be good with SpecFlow (page details, validation) and some sound like integration tests (probably good with specflow).
Once you've written all those and they pass, go back to your original test, and get the second step to pass (I click...)
And so on.
To answer your second question, hopefully you're running the unit tests and specflow tests often enough that if a test fails, it's due to something you've done in the last few minutes. It shouldn't be too hard to see what failed and match it to what you just did.
If you're not running your tests that often, then well you should be.
on the last projects i've started, I wondered if I should use the admin generator or not. My usual choice is to not use it, as some developers suggested to me, "unless it's for quick backend prototyping and submission to client", they said. Currently i'm starting a project and i'm in the situation that the client need the backend very fast to start loading lots of data, and i'm doubting about using the admin generator or not. I would use it if needed simple form fields. But one of my models must have multiple images, and maybe I need a more complex view that allow the client to load N images, so the admin generator maybe it's not the best choice, but it seems fast, it seems to save time and that's what I need now, time saving!
The project is very simple, it's just a Product model with multiple images and multiple sizes and belongs to a simple category.
What do you think? What would be the best option for this? And where do you think that makes sense to use the admin generator or the regular module generator?
Thanks in advance!
Regards.
I use the admin generator as much as possible. It is really designed to be great for the "backend" of your website-- the administrative screens which authors and editors will use to maintain the app. Any module that needs to be user-editable and is simple cries out for the admin generator.
Recently I have been starting everything with the admin generator so that there's a working prototype to build data with. Then I select certain modules or views that need more magic sauce, and build them out with more customization.
Remember, you can add views and forms to an admin generator module. On my last project I used the admin generator for the "edit" action of my main object but added "show" methods similar to a non-admin-generator form-- adding an executeShow() action and showSuccess template.
The other thing to keep in mind is that the admin generator is only a generator. It writes a bunch of code for you in cache/frontend/env/modules, but you can override any of it by building the equivalent code in apps/frontend/modules/. If you find one part of it that you can't configure with generator.yml, you can copy the file out of the cache into your module dir and hack away. I prefer to take the "out of the box" admin generator as far as possible before customizing it, though.
i've been working with symfony for quite some time now and i've been using the admin generator for simply and complex situations. It's true that it saves time when developing CRUD modules, but i dont think that is not advisable for complex cases.
I think you should use it and also learn the power of customization the generator gives you. If you have complex Forms, leave that for form classes to manage and as you said, if your forms a quite more complex to render, well you should only take care of the rendering of that only segment of the view.
But, if you decide to make if without it, you should start thinking about creating all the view from scrap, that in my case takes quite time ( i'm not so versatile wiht css).
But this is only my opinion, hope this helps you make a more rational choice!