DCI doesn't necessarily mean fewer tests - done correctly it can make testing easier since it can help to separate concerns and allow for easy testing of discrete components. I don't think this is the killer feature for DCI though; you can do this with other OO methodologies just as well.
DCI's main advantage is that it encourages you to write code that follows an "assemble the objects I need, then perform a sequence of operations on them" pattern, where the operations generally occur inside a single method. This is your algorithm, and the idea is that you should be able to read that algorithm and get a good idea of what the program is doing. Instead of relying on tests alone to verify that your program does what it's meant to, you should be able to read the code too.
Jim Coplien's talk here is a good intro: http://www.infoq.com/presentations/The-DCI-Architecture