Testing idea
77 views
Skip to first unread message
Perry Smith
Mar 31, 2013, 10:22:12 AM3/31/13
to objects-...@googlegroups.com
I watched this video:
http://www.infoq.com/presentations/integration-tests-scam
He presents something we all know. If we have two objects where one is the client and the other is the server and we are testing the client, we test to see if the client asks the right questions and if it can handle the various responses. He calls these collaboration tests. He then goes on to talk about contract tests which is the other side of the interface where we are testing the server and we need to make sure that the server can handle the questions asked and that it can reply with the replies that are expected.
This breaks down to four things. If we call the client C, server S, and interface I, then we have:
C => I and I => S
C <= I and I <= S
From the interface's perspective, this is really one thing. If it sees a question Q going from C to S, then expect a reply R coming from S back to C. This is also something a programmer can grasp. He could specify: For interface I, Question Q should have Reply R.
From that, four stubs could be created to check the four interactions. Lets call these CI (client to interface), IS, SI, and IC. (the term "stub" here means just a small chunk of code).
These four stubs each have two modes. One mode is to do their part of the checking. For example, the CI stub can check to make sure that C actually asked question Q. The other mode is a participation mode. It asks, was this stub ever used? If not, then that indicates a missing test.
The problem I have with the some of the later concepts in POODR is that testing the test doubles becomes really complicated and, at times, it feels infinite. But as she points out, if you don't do this, you can easily trip yourself up. The other danger I have a hard time avoiding is my CI and IC tests are not connected to my IS and SI tests. The interface I'm testing when I test the client is subtly different sometimes from the interface I'm testing for the server.
If you had a test rig that automatically created the four stubs and also required your expectations to come from one of these test stubs plus added in the requirement that all the test stubs are used at least once, then we would get the full coverage he suggests.
The testing process would be to create the interface specifications. And then create tests that use the stubs.
Note also, of the four tests, two of them are somewhat trivial. The test that uses the CI stub will turn around and use the IC stub sending back the response that has been specified by the interface specification. Likewise, the test that uses the IS stub should use the SI stub to validate the response.
The work boils down to writing a test to somehow prompt C into asking the question Q and a test set up to satisfy S's dependencies so question Q can be properly presented to S.
Also, it seems to me that the interface specification would be a big win. Having the expected Questions and Replies laid out for a particular interface I believe would add a lot of clarity to the inner workings of the application.
Perry
http://www.infoq.com/presentations/integration-tests-scam
He presents something we all know. If we have two objects where one is the client and the other is the server and we are testing the client, we test to see if the client asks the right questions and if it can handle the various responses. He calls these collaboration tests. He then goes on to talk about contract tests which is the other side of the interface where we are testing the server and we need to make sure that the server can handle the questions asked and that it can reply with the replies that are expected.
This breaks down to four things. If we call the client C, server S, and interface I, then we have:
C => I and I => S
C <= I and I <= S
From the interface's perspective, this is really one thing. If it sees a question Q going from C to S, then expect a reply R coming from S back to C. This is also something a programmer can grasp. He could specify: For interface I, Question Q should have Reply R.
From that, four stubs could be created to check the four interactions. Lets call these CI (client to interface), IS, SI, and IC. (the term "stub" here means just a small chunk of code).
These four stubs each have two modes. One mode is to do their part of the checking. For example, the CI stub can check to make sure that C actually asked question Q. The other mode is a participation mode. It asks, was this stub ever used? If not, then that indicates a missing test.
The problem I have with the some of the later concepts in POODR is that testing the test doubles becomes really complicated and, at times, it feels infinite. But as she points out, if you don't do this, you can easily trip yourself up. The other danger I have a hard time avoiding is my CI and IC tests are not connected to my IS and SI tests. The interface I'm testing when I test the client is subtly different sometimes from the interface I'm testing for the server.
If you had a test rig that automatically created the four stubs and also required your expectations to come from one of these test stubs plus added in the requirement that all the test stubs are used at least once, then we would get the full coverage he suggests.
The testing process would be to create the interface specifications. And then create tests that use the stubs.
Note also, of the four tests, two of them are somewhat trivial. The test that uses the CI stub will turn around and use the IC stub sending back the response that has been specified by the interface specification. Likewise, the test that uses the IS stub should use the SI stub to validate the response.
The work boils down to writing a test to somehow prompt C into asking the question Q and a test set up to satisfy S's dependencies so question Q can be properly presented to S.
Also, it seems to me that the interface specification would be a big win. Having the expected Questions and Replies laid out for a particular interface I believe would add a lot of clarity to the inner workings of the application.
Perry
floehopper
Apr 4, 2013, 4:03:37 AM4/4/13
to objects-...@googlegroups.com
Perry,
Cheers, James.
----
Aleksander Pohl
Apr 13, 2013, 11:13:02 AM4/13/13
to objects-...@googlegroups.com
Check out the Bougs gem [1], which is designed specifically to solve this problem.
Cheers,
Aleksander
Daniel Szmulewicz
Apr 14, 2013, 1:33:37 PM4/14/13
to objects-...@googlegroups.com
Hey, that's an awesome reference. Thank you so much.
When I read about Bogus, I went "oh, yes, of course". So beyond the aha moment, should bogus become my preferred fake/double library with/for rpec. What is everybody saying? I'm very curious to hear opinions of people actually using it for some time.
Kris Leech
Apr 14, 2013, 1:43:07 PM4/14/13
to objects-...@googlegroups.com
I think rspec-fire is also
meant to solve the same problem:
https://github.com/xaviershay/rspec-fire
Hey, that's an awesome reference. Thank you so much.When I read about Bogus, I went "oh, yes, of course". So beyond the aha moment, should bogus become my preferred fake/double library with/for rpec. What is everybody saying? I'm very curious to hear opinions of people actually using it for some time.
On Saturday, April 13, 2013 6:13:02 PM UTC+3, Aleksander Pohl wrote:
--
You received this message because you are subscribed to the Google Groups "Objects on Rails" group.
To unsubscribe from this group and stop receiving emails from it, send an email to objects-on-rai...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Piotr Szotkowski
Apr 15, 2013, 6:05:35 AM4/15/13
to objects-...@googlegroups.com
Aleksander Pohl:
> Check out the Bougs gem [1], which is
> designed specifically to solve this problem.
> [1] github.com/psyho/bogus
Oooh! It both checks the faked objects’ interface *and* it seems
to have spies rather than mocks! Thanks a lot for this link.
Spies vs mocks may seem like a small difference,
but spies read much better to me; I wasn’t aware
anything else than matahari¹ provides them in Ruby.
¹ https://github.com/mortice/matahari
— Piotr Szotkowski
--
If I sit here and stare at nothing long enough, people
might think I’m an engineer working on something.
[S. R. McElroy]
> Check out the Bougs gem [1], which is
> designed specifically to solve this problem.
Oooh! It both checks the faked objects’ interface *and* it seems
to have spies rather than mocks! Thanks a lot for this link.
Spies vs mocks may seem like a small difference,
but spies read much better to me; I wasn’t aware
anything else than matahari¹ provides them in Ruby.
¹ https://github.com/mortice/matahari
— Piotr Szotkowski
--
If I sit here and stare at nothing long enough, people
might think I’m an engineer working on something.
[S. R. McElroy]
Aleksander Pohl
Apr 16, 2013, 12:17:41 PM4/16/13
to objects-...@googlegroups.com
Ruby double (rr) [1] also has spies implemented. Bogus syntax is inspired by rr.
Cheers,
Aleksander
Andy Lindeman
Apr 16, 2013, 12:20:26 PM4/16/13
to objects-...@googlegroups.com
On Tue, Apr 16, 2013 at 12:17 PM, Aleksander Pohl <apo...@gmail.com> wrote:
> Ruby double (rr) [1] also has spies implemented. Bogus syntax is inspired by
> rr.
The next rspec-mocks release will have spies as well:
> Ruby double (rr) [1] also has spies implemented. Bogus syntax is inspired by
> rr.
<https://github.com/rspec/rspec-mocks/pull/241#issuecomment-15647931>
--
Andy Lindeman
http://www.andylindeman.com/
Reply all
Reply to author
Forward
0 new messages