This is a really simple library to aid in AAA style testing. The primary driver for using this is to be able to make assertions on method calls to collaborators in actual assertions and not as part of setup. It is meant to be used to complement the current testing framework that you are using to aid you when you are wanting to write an interaction based tests.
- Just gem install developwithpassion_fakes. Or place and entry in your Gemfile and let bundler do the rest!
- Import the library in the test files you are writing (I usually just place this line in my spec_helper file and forget about it):
Where’s the code
Code for the library is on GitHub. It was written test first, and it was kept clean and small on purpose, as it is meant to be used in conjunction with your existing testing solution.
Working with the library
Here is a simple example
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23
Creating a new fake
To create a new fake, simply leverage the fake method that is mixed into the Kernel module.
1 2 3
Specifying the behaviour of a fake
When scaffolding fake return values, the library behaves almost identically to the way RSpec stubs work.
Setup a method to return a value for a particular set of arguments
1 2 3
Setup a method to return a value regardless of the arguments it is called with
1 2 3 4 5 6 7
Setup different return values for different argument sets
1 2 3 4 5 6 7 8 9 10 11 12
Verifying calls made to the fake
Verifying when a call was made
The primary purpose of the library is to help you in doing interaction style testing in a AAA style. Assume the following class is one you would like to test:
1 2 3 4 5 6 7 8 9
ItemToTest is supposed to leverage its collaborator and calls its send_message method with the argument “Hello World”. To verify this using AAA style, interaction testing you can do the following (I am using rspec, but you can use this with any testing library you wish):
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
From the example above, you can see that we created the fake and did not need to scaffold it with any behaviour.
You can also see that we are create our System Under Test (sut) and provide it the collaborator:
We then proceed to invoke the method on the component we are testing
1 2 3
Last but not least, we verify that our collaborator was invoked and with the right arguments:
1 2 3
The nice thing is we can make the assertions after the fact, as opposed to needing to do them as part of setup, which I find is a much more natural way to read things, when you need to do this style of test. Notice that the called_with method return a method_invocation that will be nil if the call was not received. My recommendation would be to create a test utility method that allows you to leverage your testing frameworks assertion library to make the above assertion more terse. The following rspec sample demonstrates:
1 2 3 4 5 6 7
Using the above utility method turns the previous assertion:
Verifying that a call should not have been made
Currently verifying that a call was not made does not take the arguments into consideration. It just ensures that no calls to a particular named method were made. Here is an example:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49
As you can see, in this test we want to verify that one collaborator was triggered and the other not.
As always, feel free to fork the library and send me any pull requests if you add anything interesting!!