I'm tasked with getting a legacy application under unit test. First some background about the application: It's a 600k LOC Java RCP code base with these major problemsmassive code duplicationno encapsulation, most private data is accessible from outside, some of the business data also made singletons so it's not just changeable from outside but also from everywhere.no abstractions (e.g. no business model, business data is stored in Object[] and double[][]), so no OO.There is a good regression test suite and an efficient QA team is testing and finding bugs. I know the techniques how to get it under test from classic books, e.g. Michael Feathers, but that's too slow. As there is a working regression test system I'm not afraid to aggressively refactor the system to allow unit tests to be written.How should I start to attack the problem to get some coverage quickly, so I'm able to show progress to management (and in fact to start earning from safety net of JUnit tests)? I do not want to employ tools to generate regression test suites, e.g. AgitarOne, because these tests do not test if something is correct. 
How to drastically improve code coverage?
object oriented;refactoring;test coverage;junit
I believe there are two main axes along which code can be placed when it comes to introducing unit tests: A) how testable is the code? and B) how stable is it (i.e. how urgently does it need tests)? Looking only at the extremes, this yields 4 categories:Code that is easy to test and brittleCode that is easy to test and stableCode that is hard to test and brittleCode that is hard to test and stableCategory 1 is the obvious place to start, where you can get much benefit with relatively little work. Category 2 allows you to quickly improve your coverage statistic (good for morale) and get more experience with the codebase, while category 3 is more (often frustrating) work but also yields more benefit. Which you should do first depends on how important morale and coverage statistics are for you. Category 4 is probably not worth bothering with.