• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: OCUnit vs OBJCUnit
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: OCUnit vs OBJCUnit


  • Subject: Re: OCUnit vs OBJCUnit
  • From: Michael Tsai <email@hidden>
  • Date: Wed, 25 Jun 2003 21:44:10 -0400

On Wednesday, June 25, 2003, at 08:23 PM, James Quick wrote:

OCUnit currently defines whether to run or not run tests based on PB Build styles.
In the Build settings pane for a style with tests enabled the variable
TEST_AFTER_BUILD = YES
is set.

It seems just as easy to change the build setting as change the active targets.

It's a matter of preference, I guess. I don't like the idea of doubling the number of build styles to make testing versions of them.

I see the MockCoder implementation, which I presume just layers a FIFO
dummy encode/decode layer on top of NSCoder. I also see a MockObjects.h
which includes this mock coding protocol. I've read a bit about using Mock
Objects in design/testing in the past couple of days, but don't really understand
how this is used. Could you please elaborate?

I suppose you've already read:

<http://www.connextra.com/aboutUs/mockobjects.pdf>

A mock object is like a fancy stub. Say you're writing tests for class A, which uses class B. Sometimes it's easier to create a mock class that conforms to B's interface and returns suitable dummy values than it is to initialize and configure a B with the desired behavior. This may be because B isn't implemented yet, or because you want to test a failure mode, or because the real B is slow.

It also reduces dependencies. It might take a lot of code to set up a B so that it returns the right values when called by A. If the implementation of B changes, the setup code might have to as well. Using a mock B to test A reduces coupling.

Actually, it looks like MockCoder is the only one implemented in ObjcUnit so far, but at the time I started using it, it looked as though there was interest in creating more mock objects for AppKit, which would make it easier to test controller classes.

--
Michael Tsai <http://www.c-command.com>
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.

  • Follow-Ups:
    • Re: OCUnit vs OBJCUnit
      • From: Malte Tancred <email@hidden>
    • Programming Partners Anybody? (semi-newb)
      • From: John Devor <email@hidden>
References: 
 >Re: OCUnit vs OBJCUnit (From: James Quick <email@hidden>)

  • Prev by Date: Curious about inconsistent-seeming types
  • Next by Date: Logging framework - which and where?
  • Previous by thread: Re: OCUnit vs OBJCUnit
  • Next by thread: Programming Partners Anybody? (semi-newb)
  • Index(es):
    • Date
    • Thread