Comments on: Quick Hack: Cutting RSpec test time…

By: janmejay

janmejay — Thu, 31 Mar 2011 01:11:10 +0000

Posted the introduction to a tool named TLB, which can parallelize RSpec and Test::Unit suites across physical machines. The post is available at http://codehunk.wordpress.com/2011/03/30/tlb-rocket-boosters-for-your-build/.

By: satinder

satinder — Fri, 12 Sep 2008 04:28:42 +0000

good nice info…….

keep sharing such nice info’s…..

all the best.

By: Cutting RSpec Test Time: Continuous Integration ready rake task « codehunk

Cutting RSpec Test Time: Continuous Integration ready rake task « codehunk — Wed, 10 Sep 2008 00:56:06 +0000

[...] Cutting RSpec Test Time: Continuous Integration ready rake task Talking about RSpec test time once again….. This post is the continuation of Quick Hack: Cutting RSpec test time… [...]

By: janmejay

janmejay — Sun, 07 Sep 2008 15:50:28 +0000

This has its tradeoff(s)….
Its a little worse when it comes to performance… fixtures will be faster than this… but it ensures less maintenance… and the best part is…. it keeps weird data setup bugs down to zero…. So i kind of like it…

By: janmejay

janmejay — Sun, 07 Sep 2008 15:47:38 +0000

There is a school of thought that says Fixtures are inherently evil….(i don’t think so personally)… but thats where it stands…. People say fixtures are evil because it is capable of inserting bad data…. i have had some horrible experience with fixtures though…. Some tester had raised a bug that gave us a bad headache for some 10 days(since we could not reproduce it… and he could…. consistently) and eventually we realized that it was a data setup issue… and the data was coming from fixtures….

We use something close to ObjectMother/TestDataBuilder pattern….. We have defined maps with active record attributes as keys and valid value for them as values and have two methods create!(klass, attributes = {}) and new!(klass, attributes = {}). These methods accept an optional second argument which we merge into the valid params(which we get from a method derived from the class name, like send(“#{klass.name}_params”) that we already have defined… and then call either create! or new on the klass(Class) passed in with the new(modified/merged) map of attributes.

We use a rake task that calls these methods for various classes to create a valid bootstraping data set … just like fixtures will do…. but we are trying to write fixtures… which essentially means… we r never dealing with relational data + we are always involving model validation, to ensure whatever development data we insert… is in valid state. This is what we use in place of fixtures….

By: Lalit K. Shandilya

Lalit K. Shandilya — Sun, 07 Sep 2008 12:47:25 +0000

Ya! in case of refactoring I am fully agree with you to use DB calls instead of mocks.

What are you using for fixtures standard fixtures or any other replacement?

Thanks janmejay…for sharing, I was considering to go with 100% mock though It would be interesting to know how people are managing these refactoring issues while using mocks everywhere.

By: sunarso

sunarso — Sat, 06 Sep 2008 08:07:26 +0000

wow , thanks for info

By: janmejay

janmejay — Fri, 05 Sep 2008 14:02:51 +0000

Why not using mocks…
Well… we do use mocks…. but not for the DB backed entity….
This may not sound too convincing… but this was the reason for us to take a call… and move away from mocks…
In the last release of the same project….. We were using mocks everywhere except the model specs… When we refactored models….. we saw model specs breaking…. and the controller specs doing fine…. (When the project has more than 90% test coverage… you tend to be dependent on specs to act as a safety net for refactoring…..)
In our case… the controller specs were using mocks…. so they never failed… and the application used to start failing… This was an uncomfortable scenario….
When things like this started happening more often… we decided to stop mocking for models…. unless some really time taking step/or talking to other things… (like sendmail) was involved…..

By: janmejay

janmejay — Fri, 05 Sep 2008 13:53:41 +0000

Not using fixtures because a lot of people on my team think fixtures are evil….(i kind of understand why…..)…. they think so because it can insert invalid data….. + its a maintenance nightmare….
The models evolve… they build new associations… which may be complicated has_many :through polymorphic associations and stuff…..
Then maintaining the fixtures becomes quite painful…. because you have to set the relational looking data correctly…. and you have to maintain it in a valid state…. I personally think its not too painful….(maintaining yml(s) or csv(s)) but my colleagues seem to hate it…

By: Lalit K. Shandilya

Lalit K. Shandilya — Fri, 05 Sep 2008 11:31:39 +0000

Nice trick, when you are using fixtures with Rspec or it requires db connection.

Why are you not using mock instead of connecting to DB?

Thanks for the hack it’s really nice.