hasan's blog (বল্গ)

i was wondering how i could make my test method more organized and DR(Y)ied.
so i had a nice time while i was writing test to ensure my current modification works ok with existing setup.

i don’t know whether any design pattern or best practice is already exist on this topic.
i came up with something that is really good for me. here is a bit about my task and also the explanation about what i did.

i have a model “category” where i have the following relations -

has_many :category_mappings, :dependent => :destroy
has_many :items, :through => :category_mappings

has_many :categories, :foreign_key => “parent_id”, :dependent => :destroy

has_many :attribute_category_mappings, :dependent => :destroy
has_many :properties, :through => :attribute_category_mappings

belongs_to :category

i was applying :dependent = > :destroy with the mapping model and child categories, which are needs to be removed as a part of the category destroy process.

so i had a messy unit test method to ensure this is working fine. sorry for not keeping my old code snaps otherwise i could show the messy one. anyway here what i wrote later to make it bit cleaner than the previous messy version -

def test_destroy_category_with_dependent
category = Category.find(3)

# prepare for verification
prepare_for_verifying_related_property_mappings(category)
prepare_for_verifying_category_mappings(category)
prepare_for_verifying_child_category(category)

# perform action
category.destroy

# ensure the action
assert_raise(ActiveRecord::RecordNotFound) {
Category.find(category.id)
}

# perform verification
verify_related_property_mappings(category)
verify_related_category_mappings(category)
verify_related_child_category(category)
end

here i just sliced my test method in 2 different roles,

1. preparation stage
2. verification stage

1. preparation stage -
in this stage, i just keep log for current state or other steps which are important for later testing.

2. verification stage -
in this stage, i just verified my new state comparing with the old state (which was kept during preparation stage).
so let’s have a look on the typical code which i wrote in  my preparation and verification stage -

def verify_related_child_category(p_category)
puts “verify related child categories – #{p_category}”
now_category_count = Category.count
assert_equal(true, ((@old_category_count – now_category_count) > 1),
“No category has been removed.”)
end

this seem pretty good for me, as long as i can make my code bunch simple and easy to change.

best wishes,

i was refactoring our Item model, where we have 3 has_many with 3 mapping models.
as we are not using InnoDB based foreign key constraint, we were searching some sort of reliable solution,
which will take pressure in application layer instead of leaving it to the database.

so later we introduced “:dependent” with has_may relation. here is our top of Item model.
has_many :category_mappings, :dependent => :destroy
has_many :categories, :through => :category_mappings

has_many :property_values, :dependent => :destroy
has_many :properties, :through => :property_value

has_many :item_location_mappings, :dependent => :destroy
has_many :locations, :through => :item_location_mappings
our “dependent” flagship is destroying all related items in the item destroy process which has introduced
our flexibility and reduced a lot of code to manage such stuff in a DRY(ied) manner.

so the following unit test worked fine for us.

some bad side,
dependent delete each and every item one by one, which is big issue when you have a big chunk of dependent data.
but that is not suppose to be common in every context. we have no problem with this issue.

best of luck!

“work for fun”

yesterday, i had a pretty rough working day, i was stucked (along with my team) with some simple joining. we had the following models -

Attribute
———–
class Attribute < AR:B
belongs_to :category
end

class AttributeValue < AR:B
belongs_to :item
belongs_to :attribute
end

class Item :attribute_values
end

rails wasn’t giving much better error message, instead it was saying, “invalid type, String to Integer..”, so far i understood ActiveRecord stuff was trying to cast a string to integer.

we even didn’t know which field was doing this stupidity and so on…
so later we dug down to the rails scripts, we added few debug messages. we found “[]” was invoked to set “id” string value.

anyway, after digging more into to this issue, today i gave another try after 7 hours of nice sleep. it was about rails reserve words.

though i heard something from the rails community, but i was expecting some message or  errors which explain this issue.

anyway, i always like fail first approach. if something is not possible it should fail first. at least it should return a meaningful exception.

i believe Active Record should be patched with more clear warning or exception, if any reserved word is used for model or controller or others it should let us inform .

i have been practicing test first development (from TDD) approach for last 1.5 years. i wrote a lot of junit test cases and wrote a lot of jmock based mock objects. it was amazing work with it these tools. specially jmock was fantastics and my most favorite mocking tool.

anyway, while i seriously started ruby on rails it is about 2/3 months ago, when i formed my own rails team and started working on first commercial rails project.

at the beginning i was working on IntelliJ IDEA 6M2 on windows environment, where i found running runit test cases are taking longer than we suppose to expect. it was really annoying.

good luck i got my mac book pro where i set up all rails stuff with IntelliJ IDEA 6M2. now i could see a lot more significant difference. now i am really feeling my test environment for rails project over this environment is running more than i expected. it really leads me to belief test driven approach over rails environment is really fast.

it must be some platform related significant changes, which only the expert on that platform can assure me.

by the way, i am really loving intelliJ IDEA and rails over my mac environment.

these days i am having a lot of fun with Ruby on Rails. it seems to be like an open ground with lot of handful tools, now come up with ideas and build them up.

handful ruby based tools really helping me to let my smile back. anyway, while i was writing code on rails i am feeling something can be better practice something is not good. from now on, i will try to put them over the my blog.

their is method called “layout” which is used to define the based layout for the controller. this can be used from ApplicationController and other domain specific controller for example : “UserController”.

my team and me was used to define layout over the domain specific controller, but i belief, as we are repeating same “layout ‘template1′” code over and over, it must be better to keep inside the ApplicationController, as because all domain specific controllers are extending application controller, more over it is easy to change.

you may get a question about ajax based response, the better answer is, use render .., layout => false, that will get rid of base layout.

best wishes,