search

karmi / tire-contrib

Additions and extensions for the Tire gem
MIT License
65 stars 31 forks source link

Add test mode #8

Closed jalkoby closed 11 years ago

jalkoby commented 11 years ago

Configure tire for test mode. More information in updated README

karmi commented 11 years ago

Hi, thanks, however I'm not entirely sure how this is useful? Could you add information about how precisely people will use that?

If this is all about disabling indexing when tests run, I do believe a better option is that everybody just stubs or mocks the corresponding method? Also in unit tests, generally people should be using a build strategy, which will bypass indexing by itself?

jalkoby commented 11 years ago

No, main idea about this helper to make easy cleanup data between tests. Let's imaging next situation:

it 'spec #1' do Factory(:book, :color => 'red') #tested book ...... end

it 'spec #2' do Book.tire.search 'red' ..... end

Second spec will raise error because es return result with id of tested book which was deleted after first spec has ended

karmi commented 11 years ago

So, why not follow the database practice and just re-create the index with data in setup/before hooks? Eg. https://github.com/karmi/rubygems.org/commit/3a17730bb2243190c7679fbacb06f28be99fbad0

jalkoby commented 11 years ago

Actually it do same thing with test_mode! block, but only when it needed. I have some integration tests which open root page. Root page displays result of tire search. So when I test some stuff on this page which doesnt related to search, I also need care about search index and clean it every time. As for me, this isn't right

karmi commented 11 years ago

I have some integration tests which open root page. Root page displays result of tire search. So when I test some stuff on this page which doesnt related to search, I also need care about search index and clean it every time.

Sounds to me, a good thing would be to split the test, if the index re-creation is too heavy/obnoxious/etc. For regular Rails tests, just have a different integration test file, or a different Shoulda context, in Cucumber have a @tag, etc.

Actually it do same thing with test_mode! block, but only when it needed.

Yes, but I do worry about supporting a feature like that, explaining it properly to users, making it powerful enough to handle edge cases, …

jalkoby commented 11 years ago

Ok, I will close this pull request