Details
-
Bug
-
Status: Closed
-
Major
-
Resolution: Fixed
-
None
-
None
-
None
-
OpenSolaris 2008.11 for SUT, DB and Faban
Description
This by necessity is a meta-bug as all of the described issues were fixed in order to make the driver work correctly during testing.
When running tests on the Olio Rails Driver, the following issues were observed (some were masked by others):
- doAddEvent() is always called in a new and separate session and so fails
- doPersonDetail() is always called in a new and separate session and so fails
- doAddAttendee() is always called in a new and separate session and so fails
- Olio Rails application requires use of authenticity_token exchange between it and client for many ops
- Post Parameters for event_image and event_document are incorrectly specified
- Post Parameters added with the correct 'content_type' so as to be acceptable to the Rails app
- Rails app needs changing to accept content_typeS with '; charset=..." (Side effect of using Apache HttpClient Parts)
- Phone numbers generated by RandomUtil don't work with the Rails App
- Scraping of event page results in some invalid event ids being used to view events
- Timing for doAddEvent() is measured even if the op isn't run (no-op'd because user not logged on)
- Parsing of images from responseBuffer fails as it expects the responseBuffer to be the same as with the PHP app
- Error message when trying to view user but not logged on due to state transition from addPerson to PersonDetail
- EventDetailImages metric target is set to > 9 when there is only 1 image on each event page
- Had to change Timing to manual in several ops because of the use of Apache HttpClient
- FileLoader.java uses wrong names for thumbnails
Most of the fixes involve using the Apache HttpClient instead of the Faban HttpTransport which allows better support for Session management and for the uploading of files within a User Session. Others come about because parts of the driver are still looking for the app to behave as per the PHP App. Particular in terms of what data the app will accept and what data it returns.
I'm willing to break this out in to separate bugs, but it would be difficult to address them all separately so it's better to deliver the fixes as a single patch. There are also some additions required on the app side, as the Apache HttpClient insists on adding 'charset=' to the content_type field