From: Timothy W. <tw...@oc...> - 2002-05-31 19:03:15
|
Funny thing about SSL is that it's kinda designed to prevent just that :) Kent Beck wrote: > Could you record SSL results and play them back literally? > > Kent > > > -----Original Message----- > > From: tw...@oc... [mailto:tw...@oc...] > > Sent: Friday, May 31, 2002 6:27 AM > > To: Curt Sampson > > Cc: Kent Beck; Carl Gay; jun...@li... > > Subject: Re: [Junit-devel] ensuring that tearDown code gets run > > > > > > > > I have a similar situation with a number of SSL-related issues. To > > "mock" any part of an SSL setup is not a trival task. So I am going to > > have to rely on my existing SSL layer, and if that takes on the order of > > seconds to initialize, I certainly don't want to do it for every test. > > Ideally, i'd like to describe the underlying resources on which a test > > relies and let the test environment ensure that the resource is set up. > > This way I could run the default TestCase suite or a single instance of > > that TestCase. This would remove some of the problems that TestSetup is > > trying to solve. As Carl mentions, this is implicitly done for the JVM > > itself; all test cases implicitly require the VM as a "resource", and > > JUnit sets it up if it's not already there :). > > > > The apricot project may attempt to deal with this issue, though I > > haven't looked at it lately. > > > > > > > > On Friday, May 31, 2002, at 02:42 AM, Curt Sampson wrote: > > > > > On Thu, 30 May 2002, Kent Beck wrote: > > > > > >> At the risk of sounding like a broken record, shared setup is a > > >> symptom of > > >> excessive design coupling. It's a design problem, and can't be solved > > >> with > > >> testing techniques. > > > > > > I think you misunderstand what I'm trying to say. The "shared setup" > > > is nothing to do with design coupling in the code being tested, > > > since there's nothing at all (except a desire for efficiency) > > > stopping you from re-doing your entire setup every time. > > > > > > In fact, there is already some shared setup done when using JUnit; > > > we don't start a new JVM for each test when running a group of > > > tests, for example. We could, and that would make running a set of > > > five tests together more like running each of those five tests > > > separately, but doing that for all the tests in the project would > > > lengthen testing time considerably. > > > > > >> Once all duplication of database access logic and structure has been > > >> eliminated, you should be able to easily replace the real database > > >> with an > > >> in-memory spoof. > > > > > > Good try. But an in-memory spoof just isn't the real database, and > > > doesn't have the syntax variations, bugs and other quirks that the > > > real database has. (It's got its own, different set.) If someone > > > touches a database-accessing method, I insist in most cases that > > > there be unit tests for it that can run against every database the > > > product uses, and that they all be run before the code is committed. > > > > > > A spoof can work for higher-level stuff, of course. > > > > > >> A small number of tests that confirm the correspondance of > > >> the spoof with the real database should serve to provide confidence > > >> that the > > >> system is working correctly. > > > > > > Yeah, well, the work to write a spoof that would duplicate all of > > > the syntax variations, quirks and bugs in, say, a particular version > > > of MS SQL Server and JDBC driver would take a lot more than a "small > > > number" of tests, and just writing the spoof itself would be a huge job. > > > > > > cjs > > > -- > > > Curt Sampson <cj...@cy...> +81 90 7737 2974 http://www.netbsd.org > > > Don't you know, in this new Dark Age, we're all light. --XTC > > > > > > > |