tag:blogger.com,1999:blog-27488238.post8410543892336732324..comments2024-03-22T11:34:45.165+01:00Comments on taw's blog: Test coverage in rubytawhttp://www.blogger.com/profile/16972845140253292628noreply@blogger.comBlogger1125tag:blogger.com,1999:blog-27488238.post-86013644639470524252016-08-21T08:15:36.966+02:002016-08-21T08:15:36.966+02:00Ruby has very poor tools for coverage testing, as ...Ruby has very poor tools for coverage testing, as you point out. The main Ruby coverage tool is SimpleCov, which only provides <a href="https://www.bignerdranch.com/blog/code-coverage-and-ruby-1-9/" rel="nofollow">C0 code coverage</a>; that is, it tests that a line has been executed. (That's why you get "50% test coverage" on some files without executing a single test — because having Ruby parse the file and read the method declarations counts as "coverage" per SimpleCov.<br /><br />Your best legitimate confidence-builder then becomes mutation testing (as nicely described <a href="http://blog.arkency.com/2015/06/how-good-are-your-ruby-tests-testing-your-tests-with-mutant/" rel="nofollow">here</a> and <a href="https://blog.blockscore.com/how-to-write-better-code-using-mutation-testing/" rel="nofollow">here</a>). Mutation testing isn't a replacement for your "regular" tests; it exists to point out where changing the logic paths executed in your code does not change the outcome of your tests. This can be a real eye-opener, especially if you routinely spend lots of time, say, debugging NoMethodErrors raised by calling some method on `nil` when you expected to be calling that method on another object.Anonymoushttps://www.blogger.com/profile/12760673999356987827noreply@blogger.com