In refactoring LibriFox's search functionality,
I moved the "pagecreate" event for the search page into a function within SearchResultsPageGenerator. Now that it's inside a function, I feel like I should write tests for it (I mean, I should have written tests for it in the first place, but that's a different problem). However, I would end up writing so much boilerplate in order to simulate the ui environment of the app, that I don't really think it would be worth it to write a test. I would probably end up spending a really long time getting the test to work properly, even though the actual function would probably change very little. When something is hard to test, it generally means that the object being tested is too closely coupled to its dependencies, but in this case I don't see how I can easily decouple it from the user interface itself.
I am running into a similar problem in trying to test
this function, which enumerates over files in the filesystem. This method depends on the interface provided by the browser, and so if I wanted to write a test, I would need to mock the enumerate, onsuccess and onerror functions as well as this#continue and this#result. It's just a lot of work for something that (seems) to work just fine.
I think the problem lies in testing the objects that rely on external libraries or APIs. My code is forced to interact with these in a certain way, so my tests have to work around that. For now, I'll just leave these two examples untested.
No comments:
Post a Comment