Find unused code in a Rails app

Question

How do I find what code is and isn\'t being run in production ?

The app is well-tested, but there\'s a lot of tests that test unused code.

Answer 1

Checkout the coverband gem, it does what you exactly what are you searching.

Answer 2

Metaprogramming

Object#method_missing

override Object#method_missing. Inside, log the calling Class and method, asynchronously, to a data store. Then manually call the original method with the proper arguments, based on the arguments passed to method_missing.

Object tree

Then compare the data in the data store to the contents of the application's object tree.

disclaimer: This will surely require significant performance and resource consideration. Also, it will take a little tinkering to get that to work, but theoretically it should work. I'll leave it as an exercise to the original poster to implement it. ;)

Answer 3

Under normal circumstances the approach would be to use your test data for code coverage, but as you say you have parts of your code that are tested but are not used on the production app, you could do something slightly different.

Just for clarity first: Don't trust automatic tools. They will only show you results for things you actively test, nothing more.

With the disclaimer behind us, I propose you use a code coverage tool (like rcov or simplecov for Ruby 1.9) on your production app and measure the code paths that are actually used by your users. While these tools were originally designed for measuring test coverage, you could also use them for production coverage

Under the assumption that during the test time-frame all relevant code paths are visited, you can remove the rest. Unfortunately, this assumption will most probably not fully hold. So you will still have to apply your knowledge of the app and its inner workings when removing parts. This is even more important when removing declarative parts (like model references) as those are often not directly run but only used for configuring other parts of the system.

Another approach which could be combined with the above is to try to refactor your app into distinguished features that you can turn on and off. Then you can turn features that are suspected to be unused off and check if nobody complains :)

And as a final note: you won't find a magic tool to do your full analysis. That's because no tool can know whether a certain piece of code is used by actual users or not. The only thing that tools can do is create (more or less) static reachability graphs, telling you if your code is somehow called from a certain point. With a dynamic language like Ruby even this is rather hard to achieve, as static analysis doesn't bring much insight in the face of meta-programming or dynamic calls that are heavily used in a rails context. So some tools actually run your code or try to get insight from test coverage. But there is definitely no magic spell.

So given the high internal (mostly hidden) complexity of a rails application, you will not get around to do most of the analysis by hand. The best advice would probably be to try to modularize your app and turn off certain modules to test f they are not used. This can be supported by proper integration tests.

Answer 4

Maybe you can try to use rails_best_practices to check unused methods and class.

Here it is in the github: https://github.com/railsbp/rails_best_practices .

Put 'gem "rails_best_practices" ' in your Gemfile and then run rails_best_practices . to generate configuration file

Answer 5

I'm not very familiar with Ruby and RoR, but what I'd suggest some crazy guess:

• add :after_filter method wich logs name of previous called method(grab it from call stack) to file
• deploy this to production
• wait for a while
• remove all methods that are not in log.

p.s. probably solution with Alt+F7 in NetBeans or RubyMine is much better :)

Answer 6

Have you tried creating a test suite using something like sahi you could then record all your user journies using this and tie those tests to rcov or something similar.

You do have to ensure you have all user journies but after that you can look at what rcov spits out and at least start to prune out stuff that is obviously never covered.