|
|
Re: What Do You Think About setupFixture and cleanupFixture?
|
Posted: Feb 13, 2003 8:12 AM
|
|
> I agree that it'd be best to conform to JUnit's
> conventions as much as possible, even though it does
> involve changing some of my suiterunner-aware code. Should
> the old methods be deprecated, or just renamed? I think
> they should be deprecated, but having those duplicate
> methods in the API might really confuse people.
>
I will either change the method names or leave them the same. At this point, I believe it is too early to deprecate. We released the software two weeks ago and according to SourceForge.net, we've had 1081 downloads. I suspect most of those people may have tried it and not used it further. Most of the people who have used it have likely used it to run their JUnit tests, not write their own Suites. Those few who have written Suites probably haven't written many, and many of those Suites will not actually have used setupFixture and cleanupFixture.
Once we release this 1.0, I will not break any code in subsequent releases, but up until 1.0, I want to reserve the right to break code. One reason we released when we did was to get feedback from the public as on the API. I want to be able to use that feedback to improve the API right up to the 1.0 release. (I also want to release it 1.0 as soon as possible, so it won't be a long wait.)
>
> > I believe I opted for "cleanup" rather than "teardown"
> > because it seemed more natural and a bit less violent
> to
> > me.
>
> To me, it sounds liberating -- "Tear down that fixture,
> Mr. SuiteRunner!"
>
> But clean-up is a much better term, because that's what
> the method should do -- clean up after a test. I
> personally prefer "cleanup."
>
Yes. In this case, though, I think it would be better to use tearDown because that is consistent with what all JUnit users are used to.
> > But tonight Matt commented that he thought the method
> > names were too long because he had to type them into an
> > email several times.
>
> There ought to be an IntelliJ email plug-in somewhere...
>
Actually, most Java programmers probably don't type all characters of method names anymore anyway. Their IDE's complete it for them.
>
> >
> > 1. Leave the methods as setupFixture and
> > cleanupFixture.
> >
> > 2. Change the methods to setUpFixture and
> > tearDownFixture.
> >
> > 3. Change the methods to setUp and
> > tearDown.
> >
> > What is your opinion?
>
> #3
This morning I'm leaning towards number 2.
I realized yesterday that there was another problem with setupFixture and cleanupFixture: I am either stretching the English language by transforming "setup" and "cleanup" into verbs or not using studly caps/camel case appropriately. I believe "setup" is a noun in English, but the verb would be "set up". That means the method name should really be: setUpFixture, not setupFixture.
I still have the same problem I originally had with JUnit's names setUp and tearDown. mySuite.setUp() tells me you are setting up a Suite, not setting up a Suite's fixture. mySuite.setUpFixture() says what the method is doing. You are setting up a Suite's fixture.
If we change the method names to setUpFixture and tearDownFixture: 1) They will have proper camel case. 2) They will be consistent with -- though not exactly the same as -- JUnit naming. 3) Most people will use code completion to type the names anyway, so the extra 7 characters aren't so costly in finger typing. 4) They will be clear about saying what they do in their name.
Comments?
|
|
Previous Topic
