I have gone through fitnesse user guide. But it seems difficult for me to follow since I want to test a web-service.
The problem is as below
I have a request xml file and response xml file.
In request file I have userid and logon id with values .
In response xml file I have location with value.
I need to test that whether I get expected location value , using fitness.
How can I do the test with fitnesse.
Out of the box FitNesse does not test anything. It is really a framework for collaboratively editing and executing tests. To test any sort of software you need to use fixtures. Often people write their own, but you can also use fixtures written by other people.
In the case of testing web services, you can possibly use RestFixture. It is designed to test REST based Web Services. Back when I had to test a TES interface, I chose to write my own using HttpClient and custom parser due to the way our other test fixtures worked.
I don't know anything about it, but you can also look at XmlHttpTest.
Ultimately, you with have to find a fixture that works for you, or build one. This is pretty much true of FitNesse, Cucumber, and most of the similar style tools.
Related
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'm currently creating rspec test cases for a Rails 2.3 application. The problem I'm confronting is that the application has a dependency on data from an external database like this:
Main_User is an external application.
Node_User is the application I'm testing.
When a new Node_User is created, Node_User calls Main_User which creates a user and returns with some data which Node_User uses to create a the Node_User.
Is there any way I can query the Main_User database to verify that the record created there contains the data that is passed to Node_User? Or is there a better way to test this?
Thank you!
Yes, you can theoretically query the remote database if you have access to the user/pass/hostname for that database. (Search for "Rails multiple databases.")
But I wouldn't necessarily recommend taking that approach. Your tests would be modifying the state of the remote database. This strikes me as unsafe. You'll be creating bogus records--and possibly deleting or corrupting data, if your tests do any mass deletes or exercise broken functionality. In other words, your tests may do bad things to a production database.
Therefore, I would recommend mocking the remote database in some way. One option would be VCR. It's really cool, but it would require you to operate on the remote database at least once, because it has to record the first run. Another option is to use one of the tools underlying VCR, such as FakeWeb.
Of course, this only tests the Node_User side of things. You said you also need to verify that the remote record is correct. To do that, I would recommend writing tests on the Main_User side. Such tests would simulate an incoming RESTful request from Node_User and verify the correct result.
That only works if Main_User is your application. If it's a third-party service, then there may not be a safe way to test it. You may just have to trust its correctness.
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.
Currently working as a coach in an ATG shop and would like to introduce some form of customer acceptance testing. My weapon of choice is usually Fitnesse but the guys here say it's not possible to drive ATG with Fitnesse. I wonder if anyone else has tried this and, if so, what their experiences were?
Thanks in advance - davep
I'm going to assume you're talking about UI testing, rather than code-level testing; "customer acceptance testing" to me implies UI.
I work on ATG,and i use HtmlUnit and WebDriver to do UI testing, with tests written with JUnit that use those frameworks directly. Our QA guys use Sahi.
I've never used Fitnesse. However, following a quick look at it, i don't see any showstoppers. You'd want to write fixtures that used HtmlUnit or WebDriver (i'd recommend WebDriver) to hit the site and do things in the fixture methods. This would involve three running processes: the Fitnesse server, a process running the fixtures, and then ATG itself. I wouldn't try to run the fixtures inside ATG. Not for UI testing.
Is that the sort of thing you were thinking of?
The recommended way would be to expose an API (e.g. REST+JSON web services) from ATG, and use Fitnesse to drive that.
This has the advantage of, not only being easier to test, but also supporting responsive HTML 5 and native mobile applications.
Depending on your version of ATG, there are various mechanisms in place to expose a component as a REST service. Better yet, though, take a look at Mobile Cube (http://www.deliverycube.com) as a framework that can be used to build a REST API on ATG. (full disclosure, I designed the framework)
In my current project we are using FitNesse to test application, that use ATG.
We use dyn admin injection fixture for preparing test data (for example, to creates a web user).
And than we use steps according to a usual test scenario.
What do I need to learn, where should I go learn it. And why is your recommendation the way to go.
My app has your standard forms, like signin, reset password etc...
The app also has an email ingest library which I want to write automated tests for.
Where should I start? Thanks
There are a lot of testing frameworks for Ruby and/or Rails: RSpec, Cucumber, TestUnit, MiniTest, Shoulda to name but a few. I would recommend trying them out and finding one that best suits your needs. It usually comes down to a personal preference. No framework is always better than another. I have found that some of my projects actually work best when I write tests using a couple of these frameworks depending on what I actually want to test.
As for testing email functionality, I would recommend picking a testing framework, say TestUnit (which is built into Ruby) and going with it. One thing I would make sure to do is to write tests that don't rely on your code actually receiving emails. That way you are testing your implementation and not whether or not emails are actually being sent or received. For example, you could use mocks and stubs to fake actual email data and actual email interactions. You could also write a test class that mimicks an email interface for receiving and sending emails and test that your code can interact with that. Whenever possible try to test only your implementation and not external dependencies.