I want to test a method of a class “Service”
The problem is, that Converter provides no way to determine which drawings have been added. So I tried the following, like I would have done in Java – subclass the Converter and add the needed methods.
>> more…
Finally I found a case, where I really like C# regions: to structure unit tests. Usually there is more than one test per method and finding the place, where the testing of one method starts and the other ends is quite annoying.
In all other classes I still think that the only use of regions is to find which parts of a class should be extracted into a new class 
To achieve full test coverage for our new product sixbee, we chose to try out Selenium. It works perfectly fine for simple stuff like clicking on static links with static texts or IDs:
When it comes to testing components using Ajax, it’s getting trickier, as not all generated elements have an ID to reference it. Fortunately, Selenium offers some more possibilities for locating elements, such as XPath or CSS-selectors: >> more…
Grails claims that it encourages writing test – for example, a test class is created every time you create a controller or domain. However, working on my first Grails project I find it quite confusing which kind of test supports what.
For example, we use GreenMail in our testing environment. To check for sent mails, we have to use GrailsUnitTests, even if we are testing a Controller, because the content of mails is always empty in ControllerUnitTests.
Checking view names or redirects in those two types of tests is also slightly different:
This is pretty annoying and I hope it will be unified in future versions of Grails.
Sometimes the easiest way is the right one – after a considerable time of research, trial and error we figured out, how to pretend to be a certain browser in a grails tests:
The information is stored in the request header, so the obvious solution to add an user-agent-header worked. That we didn’t even consider this solution at first is maybe a sign that testing in grails seldom does what you expect…
Grails supports filters, which are applied to each action – before or after executing the action or after rendering. The scope of those filters can be constrained by a regex-like syntax to a subset of all actions.
That’s a pretty neat method to check for authentication, incorrect parameters etc. Unfortunately, filters are not applied during unit or integration tests – you need functional tests that simulate http-requests and responses to verify they are doing the right thing.
Grails does not support functional tests directly, you need a plugin (we chose “functional-test”): >> more…
There are more pleasurable things then wading through the fitnesse documentation with its table style, so whenever I don’t remember some fitnesse key word, I’d rather hesitate and wait for an inspiration before going there. This is to memorize the key words to be used in do fixtures.
Usage like this: >> more…
In the past year we noted a heavy decrease in performance, espescially for new featueres we introduced. That’s because our standard testing and sign-off process did not include performance tests and we have not yet had any good ideas (that means, realizable with an adequate amount of time and effort) how to automate it.
In the last couple of months we spent a lot of time to get back to our old standard (which we even managed to outperform in some cases), take care of not ruining the performance again by testing it before releases and treat freshly introduced performance issues with the same priority as post release bugs (that means, fix them immediately). >> more…
With JDK 6 new possibilities open to developers. JDK 6 includes scripting API and one its implementation – Mozilla Rhino – Javascript execution engine. This technology allows us to execute Javascript code within JRE and to call Java code from Javascript running by this engine. Following code will run without any additional libs in classpath:
There’s a saying “Where there’s one bug, there’s two.” Don’t stop looking because you have found a problem. Chances are excellent that there is another one nearby.
This weekend marks a historic moment for our product conjectPM – we’ve moved from complex object permissions (about 10 different permissions) to simple permissions (read, write, full access). This turned out to be a project, as we had been developing on this for 4 iterations now (1 iteration = 2 weeks).
We were careful not to underestimate this endeavour, as it resembles open brain surgery on a patient. We have had over one week of testing (initial internal tests found over 30 bugs), including tests of the migrated data.
Monday will be the moment of truth, as that’s the go-live for thousands of users…
Our support team, who are very critical testers, have been confident. No matter how many cases you test and how much test automation you can put in place, you can rely on the gut feeling of these guys. >> more…
