testing

Being able to precisely control what failures in underlying systems occur and at what time can be really useful in achieving a fast and stable test suite. While I am a big proponent of dependency inversion and being able to control dependencies via the explicit injection points in your API, sometimes it’s impractical to do so. This is where fail can help us immensely, providing an escape hatch for situations like those as it allows to inject failures into previously defined failure points. [Read More]

I am fascinated by the concept of fuzzing. It fits well with my desire to test weird code paths by using more of computer’s time and less that of a programmer. What is fuzzing ? It’s a type of automated testing, especially good with finding edge cases in your code. It runs totally outside of your code and knows nothing about it - it just throws random data at it. Modern fuzzers instrument your code to be able to tell if by changing input they change the code paths covered and by doing that they try to achieve maximum coverage. [Read More]

Sometimes you just have a bunch of example data laying around and you want to make sure your code works with all of them. Some of them are probably short and sweet and could live happily as doctests, which are amazing btw. But some of them are more awkward to present in such form, because, for example, of their size or number. Typically when you have an example of how the program should behave you write an example-based unit test. [Read More]

Use verbs as test module names Who said that the test module needs to be named test ? Experiment with different module names, pay attention to how the test runner displays the results. A structure that I like, an example: worker.rs: // some production code here mod should { #[test] fn consume_message_from_queue() { // mock queue, create worker with that queue injected // start worker // check if queue's 'get_message' was invoked } } Cargo prints worker::should::consume_message_from_queue when running this test, which reads nicely and exposes the requirement. [Read More]

Rust: controlling side effects from the test. Hello and welcome to the newest episode on testing in Rust. Imagine you want to write a timestamping repository of some sorts, that will associate the timestamp of when the storage operation was invoked with the stored value. How to write it in Rust ? And more importantly - how to test it ? I would like to share a solution I found and talk a bit about how it works. [Read More]

I run Android tests on CI and after having switched to Lollipop recently the integration tests wouldn’t run. Invoking androidConnectedTest gradle target always resulted in crashing with ShellCommandUnresponsiveException. Internet says that in such a case ou just need to set ADB_INSTALL_TIMEOUT. I tried to no avail. Sourcediving it is then ! A long while after that I got to this file: Device.java [Linking to master, here’s the commit hash:1cb1a4c2976b99ae53d28d7f01d975232c85f990, as I don’t seem to be able to find how to link to that hash directly] What do we see there ? [Read More]