From: Nat P. <nat...@gm...> - 2007-09-12 19:44:32
|
One thing that might be worth investigating is why the tests are so brittle. Why does a change to a class (adding a new event) cause many tests that are testing other aspects of that class to fail. Maybe events can be split up somehow and tested separately. --Nat On 12/09/2007, rdr...@ar... <rdr...@ar...> wrote: > The problem still remains... > > I would have to do a lot more "Copy&Paste" inheritance if i am unable to override a speccific setup. For a simple view with 5 Events i would have to create 5 different setup functions, which would all differe in one line. And there is no way to refactor this out. > > Thats 25 (n^2) Lines of mock setup vs 10 (2 * n) lines... and the number only gets bigger for more events. The code is not complex, but it leads to maintenance problems if there is a change... > > If I want to add another event to the view, this would cause no less then 5 failed tests, and force me to update 5 Setup-functions, and create a new one from scratch (by Copy and Paste). on the other Version I would only have to update the generic setup function, and then add one event in my test-method... (or use the hack which I find ugly...) > > I like my testcases very short and simple... I usualy feel bad when they reach 10 lines, since I consider that to complex... > > Hope this makes sense... > > Heiko > > > ----- Original Nachricht ---- > Von: Steve Freeman <st...@m3...> > An: NMock2 Development Discussion <nmo...@li...> > Datum: 12.09.2007 14:53 > Betreff: Re: [NMock2-Dev] Feature Request: "Stub" should have > alower prioritythen "Expect" > > > This still feels like the wrong solution. We went round this loop a > > while ago and it just didn't work. > > > > You might also consider having more than one test case (they don't > > have to be one-to-one with classes) to manage different combinations. > > > > S. > > > > On 11 Sep 2007, at 23:50, rdr...@ar... wrote: > > > That would be a bahavior which would fix my "problem". > > > > > > Maybe enable a flag in the mockery which defines the "search order" > > > for the expectations? > > > > > > I would find this behavior much more logical then the other way > > > around. Without it i have no way to override something i setup once > > > without resulting to "trickery" (e.g. defining something that i > > > consider a stub to be an expect.once so i can "remove" it with the > > > exact call) > > > > ---(SNIP)--- > > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2005. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > NMock-two-dev mailing list > NMo...@li... > https://lists.sourceforge.net/lists/listinfo/nmock-two-dev > |