Comments for Inforbiomatica

Comment on Pair programming and microarrays by Abhishek Tiwari

Abhishek Tiwari — Tue, 17 Feb 2009 20:00:01 +0000

recently there was a publication about how it is difficult to reproduce microarray experiments, mostly because the experimental conditions are not annotated properly, but I guess when more eyes will work together it can be improved. between nice blog, one more in my list http://www.abhishek-tiwari.com/2009/02/30-blogs-about-bioinformatics-and.html

Comment on Chained Selenium RSpec examples by Moses

Moses — Sat, 14 Feb 2009 02:36:07 +0000

Thanks for your comment. We chain in order of appearance, nothing special needs to be done for that to happen.

Also, we haven't looked a cucumber much yet. We have existing infrastructure that we'd like to restructure sometime, but for now it works pretty well, especially the code for the actual tests. For our team, I am not that excited about plain text tests. Developers write all of our selenium specs right now. If some day that changes, then we'll probably get more motivated to look into cucumber.

Comment on Too many mock objects == ruby refactoring death by Moses

Moses — Sat, 14 Feb 2009 02:32:35 +0000

Test granularity: definitely not too coarse : )

When we first started testing, we were bitten by the "add a fixture and a bunch of random tests break" phenomenon a few times. That was one of our motivations to move heavily into using mock-based testing. After mock-based testing bit us also, we eventually converged on the following approach to test data: use fixtures for things that are really basic and fundamental, and therefore won't need to be added to often; use the ObjectMother pattern (which goes by many other names, basically a test data factory) for one-off objects with specific states needed by your tests; use mocks when test data setup is just too arduous, or if needed for performance or some kind of external dependency.

Thanks for your comment!

Comment on Developer testing is not primarily about design by Wolfram Arnold

Wolfram Arnold — Sat, 14 Feb 2009 00:54:26 +0000

And there is one more effect I would add: By adopting a test-first process, you’re frontloading all the questions and uncertainties and miscommunications. If the developer can’t formulate a concise test, chances are they’re not fully clear about the requirements. It’s better to flush this out at the beginning when it’s cheap to fix, than implement something that’s off-spec and let QA (if you still have it) or, worst (because most expensive) the customer find it.

Comment on Chained Selenium RSpec examples by Wolfram Arnold

Wolfram Arnold — Sat, 14 Feb 2009 00:49:44 +0000

This is an interesting idea, the chaining of examples. I've run into this before--the desire to walk through an entire workflow and it creates monster tests. Are you chaining in order of appearance, or do you have to name methods such that their alphabetical order is the order of execution you want?

A note on your last comment: Have you looked at Cucumber for integration testing? The rspec.info site now explicitly recommends it.

Comment on Too many mock objects == ruby refactoring death by Wolfram Arnold

Wolfram Arnold — Sat, 14 Feb 2009 00:43:17 +0000

Hehe, it's a long running debate. Mocks vs. fixtures. Rspec brought many advantages that I like, such as being able to test views and helpers and controllers all independently of each other. Oftentimes with the right granularity you can make those tests pretty lean and mean.

Having said this, mocks are no end-all be-all as some of the fervent proponents have you believe. Mocking association proxies are a pain, for example. I've not yet heard a good answer to this.

Some projects out there are trying to centralize the mocks, these may be worth a look.

On a wider perspective, though, I've observed a very similar problem to what you're describing--you make one implementation or API change--and all hell breaks loose with your tests, even in a fixtures-based test environment, and this typically happened when new fixtures were added to add more variety to the demo data, so as to model a new case. The upshot conclusion from this for me has always been that data and tests were too tightly coupled. So, not knowing anything about your application, I wonder if your test granularity (and thus code granularity) is too coarse?

Comment on Pair programming and microarrays by Bookmarks about Microarray

Bookmarks about Microarray — Sun, 04 Jan 2009 08:45:05 +0000

[...] – bookmarked by 4 members originally found by stevemathew on 2008-12-08 Pair programming and microarrays http://www.moseshohman.com/blog/2008/07/09/pair-microarrays/ – bookmarked by 6 members originally [...]

Comment on Too many mock objects == ruby refactoring death by Kevin Olbrich

Kevin Olbrich — Thu, 13 Nov 2008 21:17:57 +0000

The most recent version of RSpec now supports ’stub_model’s. These use real objects that created at the time of use and cannot be saved to the database. They have the advantage of allowing you to stub out attributes and still be able to call actual methods on the object. This way you end up only stubbing the data and not the behavior associated with an object.

Comment on DTrace predicate hack by richw

richw — Sat, 08 Nov 2008 02:32:25 +0000

good original post. fwiw, dtrace is a fantastic tool, though i'm also confused by the lack of text searching (dare i bring up RE?) within the predicates.

i really hope i just haven't found out how to do it instead of it not being there at all....

Comment on Slow Rails migrations, Ruby GC, and a MacPorts portfile by roger

roger — Wed, 20 Aug 2008 21:00:51 +0000

I see this this port install the famous ‘gcpatch’ for the existing interpreter. Cool.