• 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: Unit testing framework suggestions?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Unit testing framework suggestions?


  • Subject: Re: Unit testing framework suggestions?
  • From: Marcel Weiher <email@hidden>
  • Date: Mon, 27 Sep 2004 00:20:07 +0100


On 26 Sep 2004, at 12:01, Marco Scheurer wrote:

On Sep 26, 2004, at 01:33, Georg Tuparev wrote:

One reason is that tests can have their own state and ivars, and it wouldn't be a good idea to mix this with the class you want to test.

You might be right is theory, but at least I and all the people I enjoyed working with almost never kept state between two tests. Actually, if I think very hard, I cannot find a single case where my need of using state was not because of stinky code - or bad design, or bad refactoring.

I admit that it is not frequent, and one could certainly go away without that possibility.

Precisely. So you should create a design that allows for the infrequent case, but caters to the frequent case.



Another is that a lot of stuff is usually done in the TestCase class, so that writing a test is as simple as writing a single method in a subclass of TestCase.

Luckily we have categories in ObjC. And no one stops you putting this "lot of stuff" to a category of NSObject :-) But more importantly, there is no need to have a lot of stuff in TestCase class.

Yes, as I said that's a possibility. And then in order to keep your files shorter you may want to put the testing categories in separate files, and if you do so you gain nothing by having the tests in a category instead of a subclass of TestCase. However you have lost some flexibility, like the ability to store a state when you need it.

The opposite is true. You do not lose any flexibility, because you always *can* create a new class if you want to, with all the state you require. You just don't *have to* create a new class, for all those times where you don't need it.



_______________________________________________ Do not post admin requests to the list. They will be ignored. Cocoa-dev mailing list (email@hidden) Help/Unsubscribe/Update your Subscription: This email sent to email@hidden
References: 
 >Re: Unit testing framework suggestions? (From: Tim Hart <email@hidden>)
 >Re: Unit testing framework suggestions? (From: "M. Uli Kusterer" <email@hidden>)
 >Re: Unit testing framework suggestions? (From: Marco Scheurer <email@hidden>)
 >Re: Unit testing framework suggestions? (From: Georg Tuparev <email@hidden>)
 >Re: Unit testing framework suggestions? (From: Marco Scheurer <email@hidden>)

  • Prev by Date: Re: Unit testing framework suggestions?
  • Next by Date: Re: Unit testing framework suggestions?
  • Previous by thread: Re: Unit testing framework suggestions?
  • Next by thread: Re: Unit testing framework suggestions?
  • Index(es):
    • Date
    • Thread