Posted by Arjan Molenaar in the early morning: June 1st, 2011
In the first installment on Xebium, Cirilo explained the ideas behind this FitNesse fixture:
Xebium creates a simple way to use Selenium IDE (low learning curve) and FitNesse (ease of maintenance) to it’s fullest when it comes to maintaining a web application test suites.
Xebium is using the same keywords as Selenium IDE. This has the huge advantage that no person should learn another DSL. Since tests are stated this way, they can be copied between Selenium IDE and FitNesse without a hassle (the FitNesse formatter for Selenium IDE is rather trivial). And to be honest: as long as there are XPath and Regular Expressions in the code, it makes no sense to come up with a substitute for verifyText
.
Posted by Cirilo Wortel in the late afternoon: May 4th, 2011
Introduction
When testing web interfaces, it’s convenient to use an intuitive tool like Selenium IDE, it’s easy to use and can be used by non-technical people, but it is solely meant for record and playback of test-scripts. One of its limitations is that it misses sufficient options for documenting and managing tests. Furthermore it misses an interface with the backend of the system under test (SUT), to setup preconditions for a test or for instance to manipulate or read from a database.
Fitnesse is a great tool to do just that, it has the Wiki to manage tests and it by default has a setup and teardown mechanism, it’s easy to add non invasive testfixtures to interface directly with your SUT. The downside is that it is incapable of doing webtests.
We now have the glue that combines the two, it’s called Xebium!
Posted by Iwein Fuld in the early evening: April 14th, 2010
A lot of automated acceptance testing pioneers have come around and denounced their fate in heavy automated test suites. A recent article on InfoQ sums up the trend quite nicely. I am not going to jump on that bandwagon, but I will try to find the safe middle ground between the overzealously created maintenance burden and anarchy. The main point is that automating acceptance tests is the way to go, you just shouldn’t automate and maintain useless tests. The tricky part is to find out what tests are useful and what tests are not.
(more…)
Posted by Erik Rozendaal in the early morning: November 18th, 2009
Besides organizing a Scala workshop at the J-Fall meeting we also presented five technical posters to serve as discussion points for anyone interested (or just walking by). Unlike traditional meeting sessions we could interact directly, somewhat similar to open space sessions.
(more…)
Posted by Vincent Partington around lunchtime: July 11th, 2009
In the previous blog in the JPA implementation patterns series, I talked about the three default ways of mapping inheritance hierarchies using JPA. And introduced one non-standard but quite useful method. This week I will discuss various approaches to testing JPA code.
What to test?
The first question to ask is: what code do we want to test? Two kinds of objects are involved when we talk about JPA: domain objects and data access objects (DAO’s). In theory your domain objects are not tied to JPA (they’re POJO’s, right?), so you can test their functionality without a JPA provider. Nothing interesting to discuss about that here. But in practice your domain objects will at least be annotated with JPA annotations and might also include some code to manage bidirectional associations (lazily), primary keys, or serialized objects. Now things are becoming more interesting…
(more…)
Posted by Himanshu Gupta just before lunchtime: April 27th, 2009
Traditionally acceptance test was difficult to integrate with web. Now with combination of fitnesse and selenium you can do the integration easily.
Posted by Cirilo Wortel around lunchtime: April 23rd, 2009
Recently I was challenged by a client to test a new web application in an Agile project. The team was new at working Agile and even more with working together with a functional tester, altogether this resulted in me getting very little development support from the team.
Because the lack of tooling and support I focussed my efforts on just recording test-scripts using Selenium IDE, hoping I would be able to reuse them once I got the development support I had been requesting. The plan was to integrate the pre-recorded scripts in a more extended test environment in a later stage of the project.
Posted by Erik Pragt around lunchtime: July 29th, 2008
The problem
What if you’re working with Maven, where you’ve got all your dependencies nicely organised, and now you decide to use any other piece of ‘classpath-aware’ software, like Fitnesse. The chances are that you’ll need to use the same classpath in Fitnesse as in Maven. A possible solution could be to maintain it by hand, but why not write a very small script for it to do it for you? My (very very very!) basic solution is to use a Groovy, because it’s easy to write, easy to read, and easy to use!
(more…)
Posted by Maarten Winkels late at night: July 8th, 2008
For automated acceptance testing we use the Fitnesse framework. Fitness is a Wiki page that enables testers to write executable tests as Wiki pages. Wiki pages are made up from text as comments and tables as tests. To integrate the tables with the application code, developers write Fixtures. Fixtures are a very thin layer of software that invoke application code and can be exposed on the wiki. The system is very easy to use.
There are a number of useful fixtures included in Fitnesse, but by far the most useful fixture comes from a separate library (FitLibrary): The DoFixture. A DoFixture exposes every public method as a row in a table. Every odd cell in the row is a part of the method name and every even cell is a parameter. This makes the table easy to read. The row
| train | 123 | leaves | Amsterdam | station at | 12:00 | to | Utrecht Centraal | station |
will thus invoke the method trainLeavesStationAtToStation(‘123’, ‘Amsterdam’, ’12:00’, ‘Utrecht Centraal’). As you see, the words in the odd cells are concatenated in camel case.
Unfortunately not all features of this fixture or the Fitnesse framework are well documented and easy to find. This blog will list a number of features that can improve the efficiency of using Fitnesse. The features shown are fixture loading, parse delegates and system under test. To enhance the usefulness of the last feature, we will also look at some improvements.
This blog is based upon the same version of fitnesse and fitlibrary as the “Fit for Developing Software” book.