This post is part of longer series you can see more here

There are many bad practices that you can observe in the test code. Some of them are minuscule issues; others lead to critical mistakes down the line.

The central theme of this series is that most of that small ones are obscuring the view. That why finding actual issues is much harder.
Looking from this perspective, this one can be called ultimate villain

Unused code is a thing I hate the most!

But first, What is the source of unused code?
There are few reasons two most prominent are:
– Writing code just in case.
– Not cleaning old code.

I see it quite often junior testers/developers. „I was writing it, and that function seemed useful, so I created it, never used it but decided to left it just in case it will become handy.” „Oh next month we will write and Test for that functionality we will use it then.”
A region 200 line long that contains the only unused code!
Hell is paved with good intentions.
Of course, what happens next nobody remembers about that function! It becomes obsolete. So instead of rewriting it, someone will create the new version. And what happens next is
He won’t clean old code. Because he is too lazy.

So now looking at an original example.
This is one of this moment when I want to learn what was author thinking. He took his time to check the class for a code for available methods. He maybe even moved them a little to create that unused region.

But why he didn’t delete it?

The only reason I can think is he was afraid it would break something that he is unaware of. Well in actual application code I could see some value to this argument but not in the test code.
Even if that is the case – we have version control. If something breaks, we can always revert it make sure the commit is tagged.

Why didn’t he deleted it? I don’t know the gender of the author of the code it is Generic. We will return to this question later for now lest look why it is bad.

It is white noise.

Ok, so how can you fix it?

No matter what remember the most important rule of refactoring, one thing at the time and then rerun test. I know it is a pain in the ass, especially in a case of big suites of UI test that can run whole night.
In that case, I suggest creating a separate branch and still commit one change at a time to that branch. It will be easier to split bugged code from working one. Still, try to run the tests as often as possible.

But how to find the unused code?

In most cases, style checking tools and IDEs will mark it for you (ReSharper, style cop, rubocop, RubyMine, etc.).
Check manually – this one is little more complicated I don’t want you at random checking whole code. But if you have to do some changes in class. Take a look what is going in that code you may find that some code paths exist completely unused.

Also somewhere here is the discussion about why I hate c# regions but for now let’s leave it.

Note there is one point I have to make clear if you make the framework, API, etc. other solutions will use that. By very definition, some of your public classes will be unused and written just in case. But this is not the case when you are writing code for your current tests.