Hello, Can somebody help me writing a unit test for existing method of a model. I am using 2 tables like users, articles and Method is like def get_the_user_bought_item(user_id_list) users_list = User.find_by_sql(["SELECT * FROM users WHERE id IN (?)", user_id_list]) item_details=Article.find_by_sql(["SELECT * FROM users WHERE bought_by IN (?)", user_id_list]) return user_list, item_details end So i need to write a unit test for this. How that unit test should look like? Thank you sumanth
on 2008-11-27 13:40
on 2008-11-27 13:52
On Nov 27, 9:04 am, "sumanth tt" <email@example.com> wrote: > user_id_list]) > item_details=Article.find_by_sql(["SELECT * FROM users WHERE bought_by IN > (?)", user_id_list]) > return user_list, item_details > end > > So i need to write a unit test for this. How that unit test should look > like? > pretty simple really. Setup some preconditions (fixtures, model instances created as needed, mocks etc...), call the method and assert that the results are as expected. Try the common case and some edge cases (eg user_item_list is empty etc...). Your current implementation is rather low level. That could be users_list = User.find user_id_list items = Article.find_all_by_bought_by user_id_list return users_list, items Fred
on 2008-11-27 17:01
Hey Frederick, Thank you very much. I just implemented the same way you have mentioned. As I added a test by test, I understood it well and could think of other possible cases also. If we have to check for the internal portions, we do it by inspecting (raising the variable ) while developing. If we have to do the same job by tests, how can we do that? As you mentioned i changed my way of querying as you said. Special thanks for that. :) Thanks Sumanth On Thu, Nov 27, 2008 at 5:21 PM, Frederick C. <
on 2008-11-28 03:47
sumanth tt wrote: > If we have to check for the internal portions, we do it by inspecting > (raising the variable ) while developing. If we have to do the same job > by tests, how can we do that? By designing your code for testing, and writing tests on all the little bitty intermediate methods. Without testing, these methods might be private - or worse, they might just be statements embedded in run-on procedures! But testability is more important than privacy, so more things will be public. -- Phlip http://broadcast.oreilly.com/2008/10/testing-rails...