Below code example seems to work for Rails 3.0.6, devise 1.1.5, declarative authorization 0.5.3.

The sign_in test helper from devise adds the key/value pair “warden.user.user.key” => ["User",id] to the session and one has to explicitly add the session to the declarative_authorization get_with helper. The *_with methods call the request_with method which defaults the session argument to an empty hash unless one explicitly provides the session.

And without the above mentioned key/value pair in the session when calling get_with, one will not get past devise’s authenticate_user! before filter.

The following test in the users_controller_test.rb works when trying to access the users_controller show action which is included in the filter_resource_access and has an appropriate rule listed in the authorization rules:



Tip:If you have access to the database, create a database dump after running a test suite. If you have to do manual tests in between test suites then create a db dump before AND after. This will make your life a lot easier if your tests are dependent on previous tests which they probably will be. Now if one of the tests in a test suite fails, you just reload the database and start the test suite again.

We used Selenium and found it to work very well with our AJAX enabled website, but it took some time to get the head around the topics described below. The following examples worked in Firefox 3.6.10 and Selenium IDE 1.0.7.

The documentation was pretty useful and the API covered most other topics not found in the documentation.
Selenium IDE documentation
Selenium Selenese Commands
Selenium 1.0 API

AJAX/Javascript in general

When you are using AJAX/Javascript, the web page will most likely not actually reload. Therefore Selenium will not know if and when an element in the page is available and the verify* or assert* commands will often fail. This is where the waitFor* commands come in. For all these commands Selenium will repeatedly check whether a certain event came to pass until a set time out is reached. By default the time out is set to 30 seconds but can be manually adjusted using (surprise surprise)

setTimout( timeout in milliseconds) –> setTimeout(5000) –> sets timeout to 5s
Once set, the timeout will stay at 5s.

AJAX or “in browser” popup

Many web applications now use what we call an “in browser” popup, this is NOT a smaller new browser window and NOT a Javascript alert. Most of the time it is a hidden DIV element at a relative or fixed position that is shown and hidden using javascript and might be populated with data from the server using AJAX. It is very often used for data entry and therefore will have to be tested with Selenium.

• Use waitForVisible if the element’s CSS attributes include “visibility:hidden” or “display:none”.
• Use waitforElementPresent if the element did not exist before. This will not work for the above situation because the element itself is present, even though it is not visible.

Tip:use waitFor commands in sequence if you are waiting for an element in a container. For example you have to test an AJAX action that populates a hidden DIV with a page from the server that contains input fields and then makes the DIV visible. As part of the test you most likely will have to populate these inputs fields. In that case use waitForVisible for the DIV container first and then use the waitForElementPresent for the first input field. Even though Selenium verified that the DIV is now visible, it still is not a guarantee that the browser already loaded the form with the inputs fields from the server. So the test will most likely behave slightly erratic, sometimes it passes and sometimes it will fail. Using a sequence of waitFor commands will make sure that the elements are available at the time of the test step.

Javascript alert boxes/confirmations

Javascript alerts are a bit of a problem for Selenium and there are even situations where the box has to be clicked manually. (From the documentaiton: Selenium does NOT support JavaScript confirmations that are generated in a page’s onload() event handler. In this case a visible dialog WILL be generated and Selenium will hang until you manually click OK.)

But most of the time it is possible to deal with this pesky little alert boxes. When recoding the test using Selenium IDE the alert boxes appear as normal and the IDE will happily record a “assertConfirmation” command, but when running the test, no alert box shows up and the test often fails. It is important to know that alert boxes are NOT shown when running the test as noted in the Selenium documentation. And replacing assertConfirmation with waitForConfirmation most of the time allows the test to pass.

All commands use a positive confirm, so if you want to test the negative confirmation use chooseCancelOnNextConfirmation BEFORE the action that results in the alert box.

Drag & Drop

Even complicated actions like drag and drop can be implemented using the Selenium IDE only. In our case we had the following setup to test.

• Two DIVs side by side with ids “account” and “team”, the “account” DIV containing a table of account users not in a project team and the “team” DIV containing the table of the project team users.
• The users were distinguished using their unique email address and the table position for a specific user is dynamic in both DIVs.
• Dragging a user from the “account” into the “team” DIV also opened an “in browser” popup to choose the project roles for that user.
• Once the user was moved over in the “team” DIV, we needed to check that the email address was in the table of the “team” DIV.

Tip:Don’t move the mouse when running a test that contains mouse movement commands, otherwise your mouse movements will interfere with Selenium and the test will very likely fail.

Tip:Use the echo command to check your variables in the log (works if set to info)

Acceptance tests or Customer tests are written by the client together with the developers for every requirement that is part of the specification. Whereas a requirement describes specific behaviour the client wants in the finished software, the Acceptance tests make sure that the requirement was implemented in its completeness and according to the client’s input.
As an example we can use the tried and tested password requirement:

Requirement “When a user is creating an account, he/she is required to choose an outlandishly secure password”
Acceptance Test1 Test that the password contains at least 8 characters with at least one upper case letter, a number and a symbol”
Acceptance Test2 Test that the password does not contain a word from the english dictionary”
Acceptance Test3 Test that the user receives different error messages when the password is too short, contains no upper case letter, no number or no symbol. “
In this case the Acceptance tests define now what an “outlandishly secure password” is and increase the shared understanding for this requirement. And after the tenth iteration I can make sure that these Acceptance tests still pass so I have regression testing built right in.

The many benefits of ATDD

• Acceptance Tests increase the shared understanding of a requirement because they are a product of direct interaction between the client and the developers.
• Clarifies requirements and keeps the developers focused on what the client really wants.
• Drives out ambiguity if certain behaviour is ultimately a bug (behaviour violates either requirement or tests or both) or a change request (behaviour is acceptable within the scope of requirement and acceptance tests but ultimately undesirable).
• Software delivery is now dependent on all Acceptance tests passing and with that defines when a project is done.
• Percentage of passed acceptance tests/all acceptance tests acts as a project progress indicator.
• Free regression tests for the future iterations (especially if automated).

Some ATDD drawbacks

• Client interaction is needed which can prove difficult due to time constraints
• More work for the developer if tests are automated.
• Project progress might be slower due to additional effort.

Automating ATDD
There are many tools and frameworks for acceptance test automation, even some that can be used for User Interface testing. Many of them are free and open source, so the framework can be adapted to suit the project. Automating acceptance tests is highly desirable because regression testing is a hugely important step for iterative agile development methods. The immediate drawback is that this also means the developer has even more work to do because test automation is a development task in itself.

Are Unit tests not needed anymore?
Acceptance tests are no replacement for Unit tests. Unit tests must still be written by the developers to make sure that the code they are writing is performing as it should. Unit tests are written to test individual units of source code, whereas Acceptance tests are written to test several units of source code connected by some type of workflow defined by the client.

ATDD and outsourcing
ATDD is very much suited for outsourcing because its previously listed advantages address many of the issues encountered in outsourced software development. But it is important to notice that it will only work if the project is using an agile development method and can’t be shoehorned into a waterfall based development scenario of design first, development second, testing third. ATDD needs commitment from both the project owner and also the agile supplier because the real emphasis is not necessarily on the testing itself but on the increased shared understanding that is a product of the increased contact between the two parties. Including ATDD will also most likely increase the cost of the project at the start as more time is needed by the developers to write the additional tests. The real gain comes over time as the functionality of the delivered software should with every iteration be closer to what the client envisaged in the first place and therefore should reduce the need to add or refine functionality. The Acceptance tests also act as a baseline that can be consulted if a dispute about the scope should arise.

1. A brand spanking new “Idea to Paper” Wizard that includes drag and drop actor modelling, drag and drop specification management and the brand new “Non-Functional Requirements Questionnaire”.
2. Complete overhaul of RFP/Proposal wizards to make the whole process a lot easier for both sides. Includes the ability to break down items into tasks and to move attachments from a proposal into the main project when awarding the project
3. Integrated with http://www.gravatar.com to show your global avatar. Go and create one for yourself
4. Hugely improved dashboard that now includes time graphs and better access to past progress data
5. Ability to graphically monitor activity of individual project contributors
6. Improved drag and drop support for adding/removing items to milestones and releases.
7. Estimated time management and status change integration between tasks and items the task is connected to.
8. Changes to the User Interface include streamlining of processes and a much nicer look and feel.
9. And many other smaller changes that will make your life easier

If you want to be notified when release two is ready, then signup here.

We are very excited about the fact that our service is close to “official” Beta launch (expected in February) and we are welcoming Trial customers to use the service free of charge for a limited period.

Looking forward to meeting you there.

Many companies are afraid that if they use a software development service provider, those guys will then either use the software they developed and claim it is their own or use the know-how they acquired when developing software for the next customer. The first is quite unlikely, because most of the service providers are quite happily just that and have neither the knowledge, motivation nor the resources to take the software and sell it as their own or use it to build the next big Internet service. The second is certainly true, the question is to what extent. It is highly unlikely that the next customer will ask for exactly the same piece of software. Sure some parts will be reused, but because developing software is a rather complicated process, most of the time it will be completely rewritten to fit the new application. Reality is that IP theft for software is really hard to prove (not copyright infringement which is easier to prove) and would need a lot of money to actually prove in a court. We used a simple Non-Disclosure Agreement to protect ourselves against the most obvious forms of IP theft and that was it. The biggest threat to a company’s IP is its employees because the can walk away with the software and the market knowledge that lacks most software development service providers.

When it comes to software, then copyright infringement is probably the bigger issue as most large software companies will let you know. There is also an issue with who gets the copyright in different countries. Some countries award the copyright to the contractor and not the company that hired the contractor. So it makes sense to look up the copyright law and make sure the contractor signs a legally binding document stating that he/she does not claim the copyright now and in the future for the software developed.

There is also a very interesting article in The Economist covering some of this topic: http://www.economist.com/sciencetechnology/displayStory.cfm?story_id=15479680

Once again we are not advocating that Ruby on Rails is the only right choice but at the time we felt that it was the optimal choice given our background. Ruby on Rails in the end is just a tool set and there are many great tool sets out there that have their place in the right context. At the time of the post we are still very enthusiastic about our choice.

The deciding factors for us to outsource the development were the following:

• Lack of local Ruby on Rails expertise
• Limited financial resources and the price was right
• We have developed software before
• We develop alongside them and can see their code
• Due diligence finding an offshore partner (see three part post about our search)
• Matching our developemnt process with theirs
• Solid list of requirements

We can gladly say that for us it worked very well, we got a lot more bang for the buck than if we would have developed here. Here are the key points that we think were crucial to our success:

• We felt comfortable with the company we chose from the start
• We felt especially comfortable with the team lead, a highly skilled software engineer with excellent communication skills
• Skype was available at any time for them and for us. Communication needs to stay open.
• Using IM rather then calls for technical discussion keeps a log that could be referred to later.
• Because we kept on talking with the developers daily, a personal connection formed and they got more involved in the project
• Their ideas were treated the same as ours and many of them have found their way into the endproduct. This motivated them even more
• Using an agile development process also meant that we were all working on the same iteration and as such felt like we were in the same boat
• We responded to their question in the same time frame we were expecting from them
• A shared understanding that we will come up with more requirements as time goes by and a willingness on their side to change requirements and sometimes adding a requirement without charging for it
• Our acceptance of real change requests without a lengthy price renegotiation. It started as a fixed price project and the price and time frame were adjusted according to the extensions
• From early on using the developed software to track the project

And so far we still have not met a single person from that company.




We are not advocating offshoring. What has worked here for us can also work locally but in our case we had no real choice because of lack of local expertise and limited resources. What has to be taken into account in our case is that we only partially offshored as we were part of the development team ourselves. We believe that in order to reap the real benefits of outsourced development, a company needs a mixed team, some developers are local and some offshore and that are able to interact as described above. In the future we will build a local team alongside the offshore team we used so far.

]]> http://www.outfarm.com/2009/09/offshoring-near-sourcing-or-local-sourcing-and-how-to-fit-agile/feed/ 0 http://www.outfarm.com/2009/08/gathering-agile-requirements-for-our-service/ http://www.outfarm.com/2009/08/gathering-agile-requirements-for-our-service/#comments Sat, 15 Aug 2009 15:35:29 +0000 admin http://www.outfarm.com/?p=265 In this post we will talk briefly about how we gathered our requirements for the Outfarm Service. We are using an agile development approach and will be using userstories as the basis for our requirements. A userstory is a software requirement described in one or two sentences using everyday or business language of the user. This enables non-technical business people to formulate the requirements using their own language, because they will the use the new system afterwards. And in case you wondered, yes they have to come up with the requirements, not an analyst who is already removed from their day to day problems.




There are many ways of getting the user to come up with the requirements: interviews, questionnaires and workshops to name a few. Because we build a service platform that we would use ourselves, we chose to organize a workshop. Many of the steps we used are coming from Mike Cohn’s excellent book “User Stories applied for agile software development”.




The workshop has three distinct modules:

• Role-Modeling
• Userstory gathering
• Acceptance test gathering




Role-Modeling: Every application will be used in different ways by users in different roles. The idea of the workshop is to tease out those user roles that will then be used as the basis for the userstories. We started with a brainstorming session ending up with many overlaping user groups. Next step was to consolidate and condese the overlaping roles to a few roles that define these strongly overlapping user groups. And the last act was to think about attributes such as: how often are they using the software, level of domain expertise, general goal for using the software, proficiency with the software developed and general proficiency with computers and internet. We defined our own roles first and then went on to define other roles we thought would be using this software including the person who makes the buy decision for our service.




Userstory gathering: There are many ways to gather user stories: User interviews, Questionnaires, Observations, Story Writing Workshops and working with user proxies such as product manager, sales/markting or business analyst. We used a combination of user interviews and story writing workshop to come up with a simple conceptual prototype on paper and resulting userstories. Our software is a web application so we used high level pages (no page details included) as the basis for the prototype and started with an empty page. For each role we then defined what actions they could take from here and these actions would become a userstory and add pages to the prototype from which we would look for more possible actions and add more pages. While walking through the prototype one role at a time, we asked the following questions:

• What would this role most likely want to do next?
• What mistakes could he make from here?
• What could confuse the user at this point
• What additional information could the user need?

Throughout the workshop we kept in mind to keep the discussion at a high level and to come up with as many stories as possible. And throw away the simple prototype because all the information should now be captured in the usesrstories and the prototype will only create confusion when all of a sudden someone revisits it after a month.




Acceptance test gathering: The last post is already concerned with testing, therefore we only want to add a few more things:

• Write tests before development starts as they give the developer boundary conditions during developemnet and for effort estimation
• The end user/customer needs to specify the acceptance tests with the help of the developers
• Testing is part of the process and happens throughout development and not just at the end
• As long as tests add value, they should be added. Additional tests can and should be written throughout the lifetime of the project
• Automate acceptance testing using frameworks because manual testing is error prone and mind numbing to the testers
• Acceptance tests should cover different types of testing (Functional testing, User interface testing, Usability testing, Load testing)
]]> http://www.outfarm.com/2009/08/gathering-agile-requirements-for-our-service/feed/ 0