Comments for Inforbiomatica

Comment on Agile bioinformatics paper by alex_mass

alex_mass — Tue, 23 Aug 2011 22:57:24 +0000

This is not directly a comment on your paper, but although some views on the same topic: http://alexandre-masselot.blogspot.com/2011/08/creating-scientific-bioinformatics.html

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

Andho — Tue, 23 Aug 2011 16:03:56 +0000

I think that an Aggregate root should not mock the objects it contains within it. If there are too many related objects to mock outside of the Aggregate, than that Class needs refactoring.

Comment on schemamule 1.0 released by REVERT TO CONSOLE › Automated Unit Testing with DBUnit, Hsqldb in Spring & Hibernate projects

Wed, 16 Mar 2011 14:31:25 +0000

[...] Welcome to Schemamule. It’s a tiny jar file and has a single ant task which copies the entire Oracle Schema and generates a Hsqldb database. YES. It replicates an entire Oracle Schema into a hsqldb in seconds! You can either use it as an in memory database for your automated unit testing or as dev only local database for unit testing. For more details, read the original blog here. [...]

Comment on Chained Selenium RSpec examples by Inforbiomatica » Blog Archive » Turns out, cucumber/webrat/selenium is worse

Tue, 16 Mar 2010 05:17:34 +0000

[...] of funkytown that integrated selenium tests into rspec, provided the ability to chain examples (see this blog post), as well as some webrat-like helper methods, except better, enabling code like [...]

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?