Skip navigation.

Archives

Lessons learned from building a house.

context-driven testing | metaphors
Few years ago we decided to build a family house. It all ended up not quite as we planned, but we are happy with what we have. There are a lot of lessons that I am able to map with my software project experience, especially with agile ones. Lesson number one is: not only customer is unable to define what they want; the single right „what a customer wants in terms of functionality” does not exist as it changes even as they try to define it. But let me tell you all the lessons rather than philosophy. Mapping with software testing experience is coming soon....

Pair testing

Pair testing can be challenging for a several reasons, not the least of which is just finding the time for it. But I still try to do it when I can. It’s more difficult now that I’m a manager. I haven’t really tested in months, much less pair tested. I need to work on that… [...]

Python Timing - time.clock() vs. time.time()

Dear Lazyweb,

Which is better to use for timing in Python? time.clock() or time.time()? Which one provides more accuracy?

for example:

start = time.clock()
... do something
elapsed = (time.clock() - start)

vs.

start = time.time()
... do something
elapsed = (time.time() - start)

Update:
From the comments I received and others I have talked with, it looks like the answer is: use time() on Unix/Linux systems and clock() on Windows systems. However, the 'timeit' module gives you more options and is accurate across platforms.

Clear Up Misunderstandings - Get Practical

On occasion, we find ourselves in situations where we have to accept that the way we see the world and the way some of our team mates see the world are chalk and cheese.

That I can live with. We just agree to disagree, and move on into areas where - at the very least - we don't care either way.

What can make things much worse, though, is when we don't know that we disagree.

Test Driven Development With Parameterized Unit Tests

In the previous post, we implemented the insertion method of a binary heap using Test Driven Development (TDD) and parameterized unit tests (I'll leave the full implementation of the insertion method as an exercise).

The Google Maps API Open Source Their Selenium Test Suite

The Google Maps API is one of our most popular developer products here at Google, and is also one of the trickiest to test because of its visual nature and diverse uses. It has to go through the standard backend and JsUnit testing, but then also through a suite of Selenium tests to make sure that DOM elements are positioned correctly, mouse events are triggered correctly, and even tests to address random bugs like Issue 517, where IE errored out when an implicitly closed base tag was used in the developer's HTML. And to top it off, all those tests must pass in every one of the API's supported browsers.