Currently I am working on a project that could publish a service for our clients to carry out purchase of their products. In order to carry out our functional testing, and get some visibility around the actions our service was doing, we decided to use Fitnesse for automating are functional tests.
Fitnesse is a pretty neat framework for creating different scenarios quickly using a wiki based editor taking in values for simulating different behaviors based on the value.
Since our service came into play at the end of the work flow for the entire system. We had to write many fixtures for various entities that were required by the purchase service.
Fixtures is basically the same thing as "TestFixture" for a .Nunit test. It is a class which carries out different actions based on the input provided, after which assertions are made to validate the action. This often makes us wonder, why do we need to write Fitnesse test when we can validate this with a unit test also. This is because Unit tests are pure code, and does not offer a good representation of the functionality. They do help us in documenting the roles for every method we write, but does not offer visibility to business analysts.
So, we decided any story will be called dev-complete only when the pair has fixtures for the test scenarios that the QA has written. As in as the story gets in the dev, it is also played in QA. The QA only has to worry about the scenario he is creating on the wiki. It allows him to focus on the test scenarios for the story rather then code for automating the scenario. Since there is no UI which lightens up the QA instincts, the wiki actually comes pretty close to give QA the same feel and environment to experiment with different data.
How do the fixtures work:
Fitnesse uses reflection to interact with the fixtures.
It supports easy copy with primitive types.
In order to call methods, we suffix the method name with ? or ().
In order to pass in parameters to various methods, we can use action fixture, where we define the action and parameter for that action.
Any value specified under an action is then validated with the return value. This basically acts like the expected value, which is asserted with the return value.
What i miss in Fitnesse:
Show run time output, as in I should be able to tell fitnesse to take output from some stream, be it a console a log file, and that should be displayed while running. It will make the test for interactive and responsive.
Overall I like the fitnesse test, as i don't have to go through the all web pages that come in the flow to successfully verify if my functionality is working fine or not. Especially when you are working at the last stage of the process. Just click test. :)
Fitnesse is a pretty neat framework for creating different scenarios quickly using a wiki based editor taking in values for simulating different behaviors based on the value.
Since our service came into play at the end of the work flow for the entire system. We had to write many fixtures for various entities that were required by the purchase service.
Fixtures is basically the same thing as "TestFixture" for a .Nunit test. It is a class which carries out different actions based on the input provided, after which assertions are made to validate the action. This often makes us wonder, why do we need to write Fitnesse test when we can validate this with a unit test also. This is because Unit tests are pure code, and does not offer a good representation of the functionality. They do help us in documenting the roles for every method we write, but does not offer visibility to business analysts.
So, we decided any story will be called dev-complete only when the pair has fixtures for the test scenarios that the QA has written. As in as the story gets in the dev, it is also played in QA. The QA only has to worry about the scenario he is creating on the wiki. It allows him to focus on the test scenarios for the story rather then code for automating the scenario. Since there is no UI which lightens up the QA instincts, the wiki actually comes pretty close to give QA the same feel and environment to experiment with different data.
How do the fixtures work:
Fitnesse uses reflection to interact with the fixtures.
It supports easy copy with primitive types.
In order to call methods, we suffix the method name with ? or ().
In order to pass in parameters to various methods, we can use action fixture, where we define the action and parameter for that action.
Any value specified under an action is then validated with the return value. This basically acts like the expected value, which is asserted with the return value.
What i miss in Fitnesse:
Show run time output, as in I should be able to tell fitnesse to take output from some stream, be it a console a log file, and that should be displayed while running. It will make the test for interactive and responsive.
Overall I like the fitnesse test, as i don't have to go through the all web pages that come in the flow to successfully verify if my functionality is working fine or not. Especially when you are working at the last stage of the process. Just click test. :)
