Ignoring the pros/cons of each, the fact is that there
is a lot of code out there that isn't written with
"Forced Design" in mind. As an independent consulting,
the reality is that I will probably have to work with
that code some day, regardless of what I think. It is
not feasible to rewrite this working code just to make
it testable. I appreciate the fact that TypeMock helps
me in those cases. Sadly, a lot of companies balk when
they are asked to spend extra for a mocking tool, and I
can't use TypeMock.
You're asking, so my answer is "Yes, TypeMock should
have some sort of free version of Isolator".
Yup, I used to use Isolator when it had a "community"
version, but had to migrate to Rhino when that version
has been dropped. When working at some of my clients, it
was already hard enough to make them understand why I
was adding an external framework for mocking, let alone
telling them they had to pay for one.
Can you give an example of some code you would like to
write, because it is the best API, that would be
discarded because it isn't testable without TypeMock?
You offer up a number of straw man arguments. Are you
intentionally misrepresenting TypeMock detractors, or do
you really not understand what makes use of statics, etc
"bad design" (and no, testability is not the answer)?
I agree about concrete limitation in the specific tool.
I've seen design decisions based on that MSTest did not
have rowtest.
But I don't see that design decisions driven by mocking
frameworks is worse than other TDD heuristics indicating
a design smell. You could also say that "if you need
your tests to drive the design, you are doing it wrong",
which in principle may be true, but I don't see it as a
problem.
I disagree with the notion that TypeMock usage is an
indication of bad design or bad TDD overall, but it is a
power vs responsibility situation. If you don't have any
mental red flags that go off when you veer off into
crazy tangents, you can dig yourself in waaay deep with
something as powerful as TypeMock.
"Just because you can, doesn't mean you should", springs
to mind.
It is regrettable, however, that the syntactic
differences, test code dependency and
versioning+deployment of redist assemblies makes the
choice of mocking+testing framework a somewhat
committing decision at a way too early stage of the
component lifetime.
Joshua, you are barking up the wrong tree. whether or
not I agree with statics is not the issue. it's that I
let a tool decide for me if statics are good or bad -
that's the issue.
At this stage in our development (think personal rather
than project) and with us being a small software team I
actually feel that using the free tools helps us
maintain good design patterns when using TDD (while
under increasing time pressures - as is always the
case).
The crucial need for Typemock in my opinion is getting
legacy code under test - so that it can be moved towards
a design that more fits with what works with the free
tools.
So for me the smart move for Typemock and for acceptance
within the community is for there to be a free version
that exactly mirrors the ability of the free solutions
and you can upgrade quickly if needed.
With that model adoption rates would rise and it would
be a much easier upgrade if required. Upgrading to a
paid solution has many stumbling blocks:
- Time to learn the new syntax,
- Time to configure (or finding out if configuration is
required at all),
- Time to work out are there any different versions
available (if so what are the trade offs),
- Are there multiple methods for doing the same thing
(if so taking the time to standardise the approach
across the company and making sure that the standardised
approach is the best from the start),
- ... and more which boils down to 'an unknown amount of
time to implement with unknown results'.
- And as the thing that keeps this a boolean choice it
costs money to move forward with Typemock (so the above
'problems' are magnified out of proposition to moving to
an alternative free solution).
To me that means we will never convert, because its a
big all or nothing effort, whereas if there was a
community version IMO Typemock would be more valuable
than other solutions as there is an upgrade path
available should you ever require it... so the reasoning
becomes:
- We know how to use it already and all our outstanding
questions have been answered through daily use and being
part of the Typemock community, and we did this all
while it was free and we could easily throw it away if
it didn't suit.
- It costs money but now we can estimate effectively
that with this legacy application we want to get under
test will take X more man hours with the community
version meaning that if the Typemock upgrade costs less
than the X more man hours then the decision is really
easy for this project and actually means we have it for
future projects (if needed) too.
For me it boils down to the point where I have to weight
things up and decide 'will using the full version of
Typemock save us money'? The more you make that an easy,
stress free decision the better and right now I'm not
considering Typemock but I would definitely be
interested in a community version that did everything
(for example) MOQ does - we would use it for the next
project because if it works out well it gives us more
options with no down side.
hey roy this is interesting question, to me
Well-designed objects should be context independent and
not tied to its environment; objects tightly coupled to
its environment will be difficult/impossible to use in
another context, which will always be highlighted in a
unit test. Sure by using typemock's magic, for a unit
test you can break the objects dependency on it
environment, there is not wrong with this if we are
using the same tecnhiques in production code. The main
issue is I would not use profiler API in production
code, using this in test code, simply silencing all the
feedback my tests are giving me about the design of the
object under test. The real issue is would you use
different underlying techniques in the context of a test
and production code ? For me the answer is no and thats
why i would tend not to use the feautre in typemock that
relied on the .NET Api profiler stuff
Do you consider patterns such as dependacy inversion a
code smell? Besides the fact that Moq forces me to break
up my dependancies and introduce a lot of interfaces, I
generally like the idea of following rigid design
patterns.
I tend to view the unit test as a client of the code
under test. And, in my opinion, that client is as
important as the application. Furthermore, am I really
letting the tool's limitation (moq) drive my design? In
reality, isn't it the platfom and the language that are
imposing those changes? Any bit of flexibility that I
put in my design (to serve the unit tests) might be
useful one day, who knows? I tend to draw the line when
those changes also introduce a level of complexity in
the production code that I'm not comfortable with.
Anyway, as an architect, I'm the one making the
decisions.
Roy, you make a good argument and its one I have
considered myself. That being said, I'm generally of the
"don't bother with Typemock" persuasion simply because I
have not been able to think of a design pattern where my
application would have been made more supple and loosely
coupled by using language features that are prohibited
by traditional mocking.
Of course there are always edge cases that come up,
maybe once a project an odd problem presents itself.
Though in these cases it is usually an indicator of
something that I overlooked that needs refactoring.
So what's the sales-pitch? Can you give me an example of
a pattern that I might actually WANT to apply in my
application that the other tools can't handle?
By all means let us have a trimmed down free version.
The whole wave of cool IOC-everywhere design is starting
to wear on me - IOC is a fine pattern in some cases -
not all. Besides you're not going to be refactoing
everything to make it shiny and IOC'y when consulting on
legacy systems.
I've seen your talks for 3 consecutive years in Florida,
Barcelona and Berlin - I really appreciate the pragmatic
approach to software development and testing that you
advocate and I hope that more of the "purists" can be
turned to the pragmatic side.
Shame about the guitar - I was looking forward to a new
song :-)
First, I agree that TypeMock is a totally good thing -
it tests code that you didn't write (legacy), code you
have no control over (e.g. DateTime.Now), and 3rd party
code that wasn't designed with testing in mind (e.g. a
shell extension driver). Rhino, Moq, and others can't do
this.
Regarding a free version of Isolator, I think it's a
great idea. Personally, the idea of a $800/developer
seems pretty steep. I was hoping for 200 range for small
companies like mine.
Regarding a free version,
Isolator is two things: the core, which makes all the
magic, and the isolation framework, which uses this
magic. Several other tools (CThru, SilverUnit, Ivonna,
perhaps Racer) use the core and don't need the isolation
part. So, following the SRP, it makes sense to put the
core into a separate product and give it for free or for
a symbolic price, while the Isolator and other tools
would work on top of it. So, whenever I just need an AOP
engine, I don't have to pay for a full-blown framework
with three APIs supporting two languages, I just get the
core.
It is also possible that I build my own framework on top
of that core, and this framework is used by millions,
making TypeMock a superstar. Anyway, a lot of people
would start playing with these core possibilities, since
it's like a new C#/VB version, everybody wants to try
and see what else is possible with the new features.
Another thing is marketing. Currently it's "Isolator,
the most powerful mock framework", and people, like,
"why do I need a paid mock framework, I already have
several free ones". With the TypeMock.Core it would be,
"TMCore lets you break the language limitations", and
people will go mad about it.