Adding test coverage on an existing model, part 3 - Dynamic search thingamabob
Up tonight is an attempt to test a class method named search. This class method enables the user to search for existing active jobs using a few different properties like name, ID and PO # given to the user by the client. It’s a nice piece of user functionality as it lowers the mental load for the user.
Personally, I would implement this specific requirement with an existing gem, like searchlogic or ransack, or implement a proper full-text search engine like sphinx. These are still options available, but firstly, I need to understand what exactly this method does. The implementation is as follows:
Hrm, that’s a pretty confusing piece of code. I’m not exactly sure how this is used, so let me ack this method call quickly and see what comes up. This is what I find:
Hrm, I don’t like that at all. I see a weirdly named method and I see strings that look like SQL being passed in. Let me look at the weirdly named method.
Yep, that’s what I thought. OK, I think I know how to test this now. Here are the specs that exercise both branches of that method.
Good. I know what and how. Searching is messy and I understand now why it’s best to implement an already existing solution rather than attempting to tackle one yourself. I am putting the replacement of this code with a gem high on my TODO list, which is growing by leaps and bounds.
This was a thorny one. Providing a simple and intuitive UI for users, especially non-technical ones, is hard and it leads to the mess of code like the above. Lesson learned.
