The aim of the book is quite an ambitious one - I want to cover everything (within reason) that you can do to make a legacy project better than it currently is. This includes refactoring and tests, but that's only a part of it. I try to cover the whole package, including: quality metrics and visibility; infrastructure automation; workflow and team communication; the decision about whether to rewrite or refactor; re-architecting; and various other miscellania.
The book does have one large chapter devoted to refactoring and
testing, but apart from that I've decided to leave it to the experts. Martin Fowler and Michael Feathers have already covered this topic in great detail, and there's not much more I can usefully add.