Sure.<br><br>Say I have Class A and to test it, Spec B. From a quick look at Spec B I'm able to read the 'when' and 'should' descriptions and get a rough idea what the spec covers, yet nothing detailed, to do that I'd have to read the Class and Spec in conjunction, even still, it may not be obvious if a specific method or object is mocked.
<br><br>For example:<br><br>my_important_method(meth1, meth2)<br><br>Say we have spec'ed this to test the call with multiple values for meth1, but not for meth2. MockCov allows you to easily see that meth2 isn't stubbed and therefore that the behavior of my_important_method isn't sufficiently covered.
<br><br>Whereas Heckle lets you know about insufficient specs by performing mutations, MockCov should allow you to instead _see_ where the specs are lacking. I'm not saying this is a replacement for Heckle; they should compliment each other quite well.
<br><br>The example I posted in the initial email is very poor. I'm working on an new feature that will highlight variables in the code that were returned by mocked calls (it does so using ParseTree). I'll produce a better example to demonstrate that in the next few days.
<br><br><div><span class="gmail_quote">On 27/07/07, <b class="gmail_sendername">David Chelimsky</b> <<a href="mailto:dchelimsky@gmail.com">dchelimsky@gmail.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On 7/25/07, Ian Leitch <<a href="mailto:port001@gmail.com">port001@gmail.com</a>> wrote:<br>> Hey list,<br>><br>> RSpec is great, I've been using it at work for a couple of months now. One<br>> gripe I have is that I find it hard to know exactly to what extent my code
<br>> is covered by the specs. I am aware of RCov and Heckle; they're great, but<br>> I'd like to demonstrate another perspective of coverage analysis I've hacked<br>> up.<br>><br>> The perspective is that of what is mocked and what isn't, with RCov
<br>> execution analysis mixed in for better viewing. My itch was "To what extent<br>> is my code mocked?" -- hence the name MockCov.<br>> It produces a report for each file with stubbed methods and executed lines
<br>> highlighted. From that I can easily see what my specs failed to mock and<br>> therefore most probably didn't specify any kind of behavior for.<br><br>I'm not sure I understand how you get from this report to some action
<br>you need to take. Would you elaborate with a specific example?<br><br>><br>> Here is a sample report:<br>> <a href="http://zioko.com/review_drop.rb.html">http://zioko.com/review_drop.rb.html</a><br>> (please forgive the small size of this sample, my employer understandably
<br>> didn't want me showing too much of our code)<br>><br>> You'll notice that there isn't any kind of statistical coverage summary, I'm<br>> not sure how to quantity the results and indeed haven't spent any time
<br>> thinking about it; that can come later. For now I'd just like to gauge the<br>> response to this.<br>><br>> I haven't packaged the code up yet, it's a horrible hack and needs to be<br>> reworked from scratch; I need to talk with someone on how best to integrate
<br>> it with RSpec before that happens though.<br>><br>> Let me know your thoughts.<br>><br>> Cheers<br>> Ian<br>> _______________________________________________<br>> rspec-users mailing list<br>
> <a href="mailto:rspec-users@rubyforge.org">rspec-users@rubyforge.org</a><br>> <a href="http://rubyforge.org/mailman/listinfo/rspec-users">http://rubyforge.org/mailman/listinfo/rspec-users</a><br>><br>_______________________________________________
<br>rspec-users mailing list<br><a href="mailto:rspec-users@rubyforge.org">rspec-users@rubyforge.org</a><br><a href="http://rubyforge.org/mailman/listinfo/rspec-users">http://rubyforge.org/mailman/listinfo/rspec-users</a>
<br></blockquote></div><br>