<p>Lately I had to change some code on older systems where not all of the code has unit tests.<br>
Before making the changes I want to write tests, but each class created a lot of dependencies and other anti-patterns which made testing quite hard.<br>
Obviously, I wanted to refactor the code to make it easier to test, write the tests and then change it.<br>
Is this the way you'd do it? Or would you spend a lot of time writing the hard-to-write tests that would be mostly removed after the refactoring will be completed?</p>

[{'answer_id': 7296, 'author': 'Mike Stone', 'author_id': 122, 'author_profile': 'https://Stackoverflow.com/users/122', 'pm_score': 4, 'selected': True, 'text': '<p>First of all, <a href="http://devver.net/blog/2008/07/tips-for-unit-testing/" rel="noreferrer">here\'s a great article with tips on unit testing</a>.  Secondly, I found a great way to avoid making tons of changes in old code is to just refactor it a little until you can test it.  One easy way to do this is to make private members protected, and then override the protected field.</p>\n\n<p>For example, let\'s say you have a class that loads some stuff from the database during the constructor.  In this case, you can\'t just override a protected method, but you can extract the DB logic to a protected field and then override it in the test.</p>\n\n<pre><code>public class MyClass {\n    public MyClass() {\n        // undesirable DB logic\n    }\n}\n</code></pre>\n\n<p>becomes</p>\n\n<pre><code>public class MyClass {\n    public MyClass() {\n        loadFromDB();\n    }\n\n    protected void loadFromDB() {\n        // undesirable DB logic\n    }\n}\n</code></pre>\n\n<p>and then your test looks something like this:</p>\n\n<pre><code>public class MyClassTest {\n    public void testSomething() {\n        MyClass myClass = new MyClassWrapper();\n        // test it\n    }\n\n    private static class MyClassWrapper extends MyClass {\n        @Override\n        protected void loadFromDB() {\n            // some mock logic\n        }\n    }\n}\n</code></pre>\n\n<p>This is somewhat of a bad example, because you could use DBUnit in this case, but I actually did this in a similar case recently because I wanted to test some functionality totally unrelated to the data being loaded, so it was very effective.  I\'ve also found such exposing of members to be useful in other similar cases where I need to get rid of some dependency that has been in a class for a long time.</p>\n\n<p>I would recommend against this solution if you are writing a framework though, unless you really don\'t mind exposing the members to users of your framework.</p>\n\n<p>It\'s a bit of a hack, but I\'ve found it quite useful.</p>\n'}, {'answer_id': 7327, 'author': 'Valters Vingolds', 'author_id': 885, 'author_profile': 'https://Stackoverflow.com/users/885', 'pm_score': 0, 'selected': False, 'text': '<p>I am not sure why would you say that unit tests are going be removed once refactoring is completed. Actually your unit-test suite should run after main build (you can create a separate "tests" build, that just runs the unit tests after the main product is built). Then you will immediately see if changes in one piece break the tests in other subsystem. Note it\'s a bit different than running tests during build (as some may advocate) - some limited testing is useful during build, but usually it\'s unproductive to "crash" the build just because some unit test happens to fail.</p>\n\n<p>If you are writing Java (chances are), check out <a href="http://www.easymock.org/" rel="nofollow noreferrer">http://www.easymock.org/</a> - may be useful for reducing coupling for the test purposes.</p>\n'}, {'answer_id': 7387, 'author': 'Mike Stone', 'author_id': 122, 'author_profile': 'https://Stackoverflow.com/users/122', 'pm_score': 2, 'selected': False, 'text': "<p>@valters</p>\n\n<p>I disagree with your statement that tests shouldn't break the build.  The tests should be an indication that the application doesn't have new bugs introduced for the functionality that is tested (and a found bug is an indication of a missing test).</p>\n\n<p>If tests don't break the build, then you can easily run into the situation where new code breaks the build and it isn't known for a while, even though a test covered it.  A failing test should be a red flag that either the test or the code has to be fixed.</p>\n\n<p>Furthermore, allowing the tests to not break the build will cause the failure rate to slowly creep up, to the point where you no longer have a reliable set of regression tests.</p>\n\n<p>If there is a problem with tests breaking too often, it may be an indication that the tests are being written in too fragile a manner (dependence on resources that could change, such as the database without using DB Unit properly, or an external web service that should be mocked), or it may be an indication that there are developers in the team that don't give the tests proper attention.</p>\n\n<p>I firmly believe that a failing test should be fixed ASAP, just as you would fix code that fails to compile ASAP.</p>\n"}, {'answer_id': 36117, 'author': 'Ced-le-pingouin', 'author_id': 3744, 'author_profile': 'https://Stackoverflow.com/users/3744', 'pm_score': 0, 'selected': False, 'text': '<p>I have read Working Effectively With Legacy Code, and I agree it is very useful for dealing with "untestable" code.</p>\n\n<p>Some techniques only apply to compiled languages (I\'m working on "old" PHP apps), but I would say most of the book is applicable to any language.</p>\n\n<p>Refactoring books sometimes assume the code is in semi-ideal or "maintenance aware" state before refactoring, but the systems I work on are less than ideal and were developed as "learn as you go" apps, or as first apps for some technologies used (and I don\'t blame the initial developers for that, since I\'m one of them), so there are no tests at all, and code is sometimes messy. This book addresses this kind of situation, whereas other refactoring books usually don\'t (well, not to this extent).</p>\n\n<p>I should mention that I haven\'t received any money from the editor nor author of this book ;), but I found it very interesting, since resources are lacking in the field of legacy code (and particularly in my language, French, but that\'s another story).</p>\n'}]
['https://Stackoverflow.com/questions/7287', 'https://Stackoverflow.com', 'https://Stackoverflow.com/users/573/']