|
From: Jeff M. <je...@mk...> - 2002-04-19 08:54:06
|
On Thu, 2002-04-18 at 19:40, Scott Lamb wrote:
> On Thu, Apr 18, 2002 at 12:23:57PM +0100, Jeff Martin wrote:
> > Here you go. Just drop it into ~/.vim/plugin, start up vim, type :call
> > MockIt("this.is.the.Interface")
> >
> > Easy as that.
> >
> > Still need to sort out a proper name mapping so you can do
> >
> > :mockit this.is.the.Interface
> >
> > and it doesn't put in variable names for the method arguments, but I'll
> > get there.
>
> I still say this isn't as good. Even though you don't have to manually type
> out the interface the first time,
It was a half joke really, people are trying to persuade me that I
should use an ide, coz it save you time doing a couple of things. I like
vim, it saves me hassle nearly ever single keystroke
>
> - if the interface changes (as in the SQL example), you need to manually
> sort it out. With the stubs, you don't.
Doesn't this then mean that we revert to the stub implementation, which
will thrown an exception only when it's called. Not at compilation. Well
only know about the problem when someone tries to use the mock not when
the interface was changed. I'd prefer not to have the class compile than
to silently change it's behavior. We end up loosing the advantage of
having a compiled language. This is a similar point to tim's.
> - it's more work to catch errors. My stub generator will immediately
> complain if there are conflicting methods with the same signature. (Or
> should. It needs more testing.)
> - the source code is cluttered up with lots of methods that aren't
> implemented, obscuring what actually does work.
I'm in two minds about this point, cluttered code bad, on the other
hand. You can just look at stack-trace telling you which line is not
implemented, go to the line and add the code. Works quite well I find.
>
> --
> Scott Lamb
>
Keep going you might yet persuade me ;o)
|