Posts tagged with "testing"

It might be that pythonistas really don’t like monkey patching, but as I couldn’t find a quick answer on how to mock time in Python I thought I write down here how I did it.

It’s no big deal really, just replace datetime in the module tested with a local implementation. In my case I wanted to to mock datetime.utcnow and to match the call I created a class with utcnow as a static method.

Ola has released JtestR 0.1. It seems to b a great tool for those doing Java development. I can personally not imagine doing any development these days without RSpec.

Autotest 3.5.0 is out, and the result given from Autotest is no longer a String, it’s an array of strings. So if you still want Growl to function properly just modify the .autotest slightly:

#ruby

module Autotest::Growl
  def self.growl title, msg, img, pri=0, stick=""
    system "growlnotify -n autotest --image #{img} -p #{pri} -m #{msg.inspect} #{title} #{stick}"
  end

  Autotest.add_hook :ran_command do |at|
    output = at.results.last.slice(/(\d+)\s.*specifications?,\s(\d+)\s.*failures?/)
    if output =~ /[1-9]\sfailures?/
      growl "Test Results", "#{output}", '~/Library/autotest/rails_fail.png', 2 #, "-s"
    else
      growl "Test Results", "#{output}", '~/Library/autotest/rails_ok.png'
    end
  end
end

I don’t like Fit. Believe me, I want to like it, I have tried to like it. I mean, Ward Cunningham created it for crying out loud, the man is a genius, so I am probably just missing something - right?

Every time I have looked at Fit, I always like the parts that handle column fixtures. They are clean and easy to read and generally does a really good job. Buth then we get to weird cousin Row Fixture which is not at all that easy to read and uncle Action Fixture which just won’t stop and finally family FitLibrary which does all good things but are utterly unreadble - which probably is due to my lack of experience, but then again wasn’t this intended for non-programmers?

Yesterday we discovered a small but annoying performance bug: when getting a list of languages from the JVM we did not cache them but kept on retrieving them, which turned out to be quite slow.

So, like the good guys we are we wanted to have a test that ensured that the error was not reintroduced. We looked at JUnitPerf which seemed to be appropriate - it decorates a unit test and times it. The only problem here was that we were talking about that good performance was 800 ms, and bad performance was 1800 ms. Such timings can randomly fail on a slower computer or a computer that was busy doing something else. We do not like that kind of tests.

We have got our functional testsuite working. It currently consists of more than 260 tests doing everything from the simple login to running recorded WebDAV tests and restarting Websphere etc.

We’ve done it in the way that Testing Extreme Programming prescribes, with collection of methods that are implemented both remotely and locally, running the servlets in-process. The methods are pretty high-level for a very high degree of usability.

We’ve used HtmlUnit as the basis of our tests, extending it in the high-level methods. It is a great package as it tests the JavaScript too, as opposed to recorded tests that only tests the servers response to a given HTTP request.

A few nice people commented on my posts on functional tests and suggested a few other alternatives:

• Canoo Webtest. It’s XML-based which makes it go right out my window. Sorry about that. We are a small company where programmers have to do their share of test time. This means that we are not afraid of code, in fact we prefer it.
• Jameleon. I had not seen this one, but looking at the tutorial it seems a lot more complex than the stuff we use now.
• PureTest. This is a very competent scenario recorder/player, and I do like the guys at Minq. But as I stated earlier, recording HTTP will not test your page the way HttpUnit does with JavaScript and all.

I am truly happy with the way we do it now. We have a base testcase class that provides methods like clickButton(). These methods are implemented as Strategies by both a remote HTTP implementation and a local in-process mock implementation.

After evaluating the previous named contenders for webtest tools, the winner was … none of them.

It dawned upon us that the MaxQ way of doing this, ie. recording tests, really is not the way to go, ever. What you’re really doing is testing the server from a HTTP perspective, without testing button clicking and stuff. For example, all hidden fields must be specified at every request. If you have anything Javascript based you still have no clue if this works after having these funtional tests.

We are currently in the process of improving our functional testsuite, some might say getting one. I’ve skimmed the JUnit site and have found two alternatives:

• jWebUnit. It has a really clear and simple syntax which is why I prefer it over HtmlUnit which I prefer over HttpUnit.
• MaxQ. Recorded Jython scripts.

I am not really sure what to make of it. The functional test suite must run separately from the rest of the system, which makes it a good candidate for a scripted language. However, being able to use IDEA is always better than any alternative. I am not sure either if recording is a good or bad thing.