My team recently added a RecyclerView to a screen in an Android app we’re working on. It’s a horizontal view that allows a user to scroll left and right to see content that’s offscreen. One of the challenges we’ve faced while working on this view has been testing it in our Espresso tests—specifically, testing the contents of items at certain positions. In this post, I’ll show you an Espresso matcher that can be used to aid in testing RecyclerViews. Read more on Espresso – Testing RecyclerViews at Specific Positions…
Acceptance testing is hard. It requires thinking through your entire problem and nailing down the expected outputs for a list of inputs. When working on games, acceptance testing becomes even more difficult.
There are certain aspects that cannot be tested: “Is it fun?” “Is it too hard?” Other aspects are just difficult to setup and too brittle to maintain. You don’t want your tests to break on small tweaks, like player walking speed or jump height, but you want to enforce that the core game mechanics are working: “Can I shoot another player?” “Can I jump up on that ledge?” This is the area where tests can be incredibly useful.
When writing automated system and integration tests, I occasionally find it tricky to express the precise expected value of test output. For example, I expect the timestamp on a database record to be within a second or two of “now,” but I can’t predict the exact millisecond it will be created by the web server I’m posting to. And sometimes a floating point result is off by a millionth or trillionth, because the numeric representations used in my tests are not necessarily the binary equivalent of what the code under test is using.
In the cases where I know the differences are circumstantial (and irrelevant to my test), I find myself wanting to write…
Automated acceptance tests are valuable, but they’re also easy to build badly. So to make sure you don’t end up with a frustrating pile of automated headaches, first strive to understand why you’re writing the tests. Specific goals often dictate a different set of tools or approach to your instrumentation around the tests. Done correctly, system tests are a powerful tool that can help you:
Acceptance Test Driven Development has become a popular practice for establishing and validating what done means for a feature. Cucumber has gained much popularity in validating Ruby code, especially for Ruby on Rails web applications. The Wire Protocol was added to Cucumber to support testing different languages by implementing a simple Wire Server in the target language. The Wire support allows step definitions to be written in an arbitrary language with communication over a TCP socket.