3

Given the following conditions:

  • a very old, big, C# legacy code base with no testcoverage whatsoever
  • (almost) every class derives from some interface
  • nothing is sealed

What are the practical benefits of using profiler-API-driven solutions like JustMock and TypeMock, compared to using extract&override + e.g. RhinoMocks? Are there cases I'm not aware of, besides circumventing private/protected, where using TypeMock/JustMock etc. is really needed? I'd especially welcome some experience from people having switched to one of the products.

Using extract&override seems to solve all problems when handling old legacy code, the refactoring seems dead simple, and the possibility for introducing bugs seems very minor. Is the benefit writing less test code? More beautifull classes with less virtual protected stuff? Right now, I don't 'get it', although I understand it's very helpfull to first test private methods in isolation, as public methods may be too large under the hood in such old legacy codebases.

If you don't know what extract&override is: see here.

Community
  • 1
  • 1
hko
  • 923
  • 9
  • 17
  • 2
    Too long. Did not read. What is the question? – Esko Luontola Aug 17 '11 at 17:38
  • It ranges from 1.1 to 3.5, I would rather not lock myself into a specific version limit, but I'm very curious: how does this answer influence the answer at all? Are there C# 3.0/3.5 features I can't stub/mock normally? – hko Aug 18 '11 at 07:30
  • Ah, I misunderstood your question, when I wrote that comment. Please disregard. [[[These are not the droids you are looking for.]]] – Mike Christian Aug 18 '11 at 16:48

1 Answers1

3

There are many differences between the frameworks which do not regard the technology on which the frameworks built on.

For example:

  • API - every framework has different notations and defaults (e.g. strict defaults vs. relaxed defaults)
  • Support - the propriety frameworks usually offer support with the licenses
  • Price - this is not a matter of usage but requires budget

The main advantage of Extract&Override is that it requires some refactoring, if the code you're working on is neglected, it's gives a good chance to go over it and refactor it toward better code and not just for testability.

The main advantage of using an Isolation framework is that you do not need to change the code under test (if it's a large codebase it could take long time just to refactor it for testability). In addition, the Isolation frameworks do not force you into specific design, this could be helpful if the legacy code matches better its existing design. Another feature which is useful in legacy code is swapping instances created in the code under test, usually refactoring instantiations takes more effort and this can be saved. Last thing is faking 3rd party code - using isolation frameworks you can isolate code which is not yours without using wrapper classes.

Disclaimer - I work at Typemock

Elisha
  • 23,310
  • 6
  • 60
  • 75
  • I don't unerstand your "the main advantage" sentence: If I use Extract&Override, I refactor the least amount possible to make it more testable. If I do anything else (like property DI or constructor DI or introducing a factory) this is not Extract&Override anymore. Granted, I would need to introduce Interfaces for extract&override, when they would not exist, but that#s not the case in my codebase. – hko Aug 18 '11 at 10:03
  • I fully understand the 3rd party issue, good point. "usually refactoring instantiations takes more effort and this can be saved": What do you mean with instantiations, do you have a concrete example? – hko Aug 18 '11 at 10:14
  • @hko, about the first comment - you're right, Extract&Override is simple, but from my experience usually when refactoring code, it is tempting to do a little more :) About instantiations - let's say the class under test is UT, and it uses a class A directly through it's constructor (just calls new A() ). Assuming I want to isolate UT from A, I have to pass it as parameter, so I need to change all the callers to UT. using Isolator for example, you can use Isolate.Swap.NextInstance().With(fakeObject) and avoid the additional code changes. – Elisha Aug 18 '11 at 15:40
  • Existing code that lacks tests tends to contain longer methods that perform multiple operations. I always recommend refactoring code, to extract units of work into their own methods, **before** unleashing testing tools on it. Doing so makes the resulting test code more maintainable. I highly recommend using an IDE tool for refactoring, such as [CodeRush with Refactor! Pro](http://www.devexpress.com/Products/Visual_Studio_Add-in/Coding_Assistance/), to speed things up, and to reliably make global changes. – Mike Christian Aug 18 '11 at 17:05
  • @Elisha: why do you have to pass it via constructor? I could write a virtual protected IA GetA() which returns new A(), and in my TestClass override it with return new StubOfA(), as long as A and StubOfA derives from an IA interface. Do i miss something? – hko Aug 18 '11 at 19:41
  • @Mike: that's mostly not the case with this codebase, and the devs are under high time pressure. Problem here is really convincing the young never-have-written-unittests devs that it is not dangerous, and easy too. But yes, I would like to refactor stuff, I just convinced (after weeks) the devs to get Resharper. But it won't happen in a big way, I fear. Pretty hard to convince them to test old legacy stuff at all. – hko Aug 18 '11 at 19:59
  • @hko: Haha! I am ina bit og the same situation -- working with mainframe programmers that have no concept of OOP or distributed systems. I'm trying to tell them that normalizing the database is a GOOD idea. T_T – Mike Christian Aug 26 '11 at 15:42