Hi Dawson
On Wed, 09 Mar 2005 10:26:26 -0400, Dawson Mossman <[EMAIL PROTECTED]> wrote: > Thanks for all the dialog guys. I think I wrote something that caused a > bit of a misunderstanding, when I said "convert my JUnit Tests to Cactus > tests" i really meant "copy the JUnit Test and use it as a base for > writing my integration test". I didn't intend on getting rid of the > original unit tests. > > I'm still curious, if I'm unit testing (code-logic) server-side > components such as Web Services and EJB's with Mock objects, do I need > to do it In-Container? The to approch are explain in the doc take a look at the http://jakarta.apache.org/cactus/mock_vs_cactus.html > > I will also try to take a look at your book Vincent. Publicité : I buy it myselt and think You really can do it is a fantastic book. Great job Vincent :) Nicolas > > Thanks, > Daws > > > On Wed, 2005-03-09 at 15:19 +0100, Vincent Massol wrote: > > Hi Dawson, > > > > > -----Original Message----- > > > From: Dawson Mossman [mailto:[EMAIL PROTECTED] > > > Sent: mercredi 9 mars 2005 15:01 > > > To: Cactus Users List > > > Subject: Mock objects with Cactus > > > > > > Hi Vincent, > > > I am fairly new to Cactus and am trying to understand exactly how it > > > should work. > > > > > > Our organization wants to perform code logic unit testing and > > > integration testing (we'll worry about functional testing later). For > > > our code logic unit testing, we are planning on doing JUnit tests with > > > Mock objects. > > > > > > This is the strategy I am thinking we could use: > > > 1) As we develop individual classes we will write JUnit tests using Mock > > > objects to test class methods. > > > 2) Then, as we begin to integrate components (classes), we will take the > > > existing JUnit Tests, convert them to Cactus tests and use the real > > > objects (not the Mocks). This will give us our "in-container" > > > integration tests. > > > > > > Does this sound like an appropriate approach? > > > > I really think you should keep your code logic unit tests and not remove > > them. Integration tests and tests in isolation are 2 different things and > > both are needed. > > > > Here's what I suggest: > > - you do most of your tests using mock objects in isolation > > - you add *some* integration tests just to prove that the integration work > > - you add functional tests. If they can be automated then all the best and > > you could possibly have the majority of your integration/functional tests as > > proper functional tests. > > > > > Should I be doing > > > something different? Our environment will be using Web Services and > > > EJB. Will I be able to perform my code-logic unit tests outside the > > > scope of a container, or will these need to be run in the same fashion > > > as Cactus tests (ie. in container)? > > > > The only trick for writing code logic unit test is realizing that the design > > of your application is extremely important and it may or may not allow you > > to write them easily. If you do TDD, then by definition you'll have a design > > that support them. Otherwise you may need to do quite extensive refactoring. > > > > > > > > Figuring out some of these questions would be great in understanding how > > > we can best use Cactus. Thanks for any help you can provide. > > > > Yes, I agree. This is exactly why I've written JUnit in Action (which is the > > sum of my 4-5 years of unit testing experience). It answers exactly the > > questions you're asking :-) > > > > Thanks > > -Vincent > > > > ___________________________________________________________ > > Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en franais ! > > Yahoo! Mail : http://fr.mail.yahoo.com > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
