Yeah, that is true. However, I think you have a decomposition opportunity here that you're not taking advantage of. I would refactor out these nasty detail sections into their own subroutine/object/whatever that provides both serialization and deserialization for the same binary format/algorithm/whatever. The tests are then applied against that specific unit of work. Then, you choose which unit of work you want to use and you know that it simply works. That avoids throwing away that hard-won mock data, as you so eloquently put it. Now, I'm not a TDD Nazi, by any means. I just think that many people throw out the baby with the bathwater when it comes to TDD.

Perhaps you can suggest an alternative technique for creating the mock objects? You can't algorithmically generate this data; even if you could live with large copy and paste ops, too many dependencies are involved to pull it off.

I think you're lost in a maze of twisty dependencies, all alike. You can't see the forest for the trees. I think you need to start building a toolbox of nasty binary bits that you can assemble without having to worry about how they got built.

Frankly, I think you're worried about performance too much too early. You're coupling things together that may not need to be coupled together, in order to squeeze performance out that may not need to be squeezed from where you're looking. I'd build the system in its ideal form, then profile it. The slow spots are never where you think they are.