Refactoring: Introduce SetUp Method

re: Refactoring: Introduce SetUp Method

JP — Tue, 16 Nov 2004 10:01:00 GMT

Wouldn’t this refactoring introduce execution sequenc dependencies? If the first test to run was AddBookmarkCountIsIncremented the second test UponCreationCountIsZero would fail.

re: Refactoring: Introduce SetUp Method

James Newkirk — Tue, 16 Nov 2004 10:51:00 GMT

The [SetUp] method is called prior to each test being executed. This results in a new collection being created prior to the execution of each test.

re: Refactoring: Introduce SetUp Method

Ben Lowery — Tue, 16 Nov 2004 11:48:00 GMT

Here's a simple one: why make the collection static?

re: Refactoring: Introduce SetUp Method

Darron — Tue, 16 Nov 2004 13:44:00 GMT

I agree with Ben, I wouldn't make the collection static until it was needed to make a test pass. This would seem to follow the "simple design" rule of doing the least you can do to make the test pass.

re: Refactoring: Introduce SetUp Method

Kelly Summerlin — Tue, 16 Nov 2004 13:55:00 GMT

In this simple case it's not hard to see the "intent" of the setup. But I have seen this taken to the extreme where the setup was doing way too much. In complex setup scenarios it's often hard to find/see the intent of a setup method. What's is it setting up? How is it going about doing it? All questions I find myself asking a lot.

I've also seen setup code doing setup stuff for 5 test methods but the other 30 test methods don't need that piece of the setup. In those cases I advocate having a private method that is called first for the 5 methods that must have that functionality.

re: Refactoring: Introduce SetUp Method

Darrell — Tue, 16 Nov 2004 13:57:00 GMT

Yes it does reduce the communication of the method, but no more so than code-interception style AOP. I think the price to pay is small enough that it doesn't matter, especially if your test fixture is small enough.

Also, I'm sure later you'll want to add a certain number of items to the collection for various testing reasons. I usually break that functionality out into a separate private method, which, when well-named, doesn't reduce the communication of the test.

re: Refactoring: Introduce SetUp Method

Tony Chow — Tue, 16 Nov 2004 14:54:00 GMT

BTW, if you mark a class with TextFixtureAttribute all public methods will be treated as tests, there's no need to mark each individual method with TestAttribute. I don't know why everybody keeps doing it; it's just not necessary.

Also, your example just doesn't illustrate the benefits of SetUpAttribute very convincingly. It's hardly inelegant to write one line of instantiation code for each test method; indeed it makes the logic of each test harder to decipher.

In most real tests, common code is shared by only a subset of tests in a test class, and it is far most logical to use an old-fashioned private method, which can be referred to by name in the host method. Therefore I expect the SetUpAttribute to be of limited usefulness, if not a hinderance, to code readability.

re: Refactoring: Introduce SetUp Method

Brendan Tompkins — Tue, 16 Nov 2004 15:11:00 GMT

I recently wrote hundreds of tests to cover our legacy business tier code. I created a TestBase class, and inherited all my tests from this class. In my base class, I had a virtual [SetUp]Init() that could be overridden if need be in my test fixture.

There was a good deal of setup involved for each test, mostly setting up user principal objects to flow through the tiers, and this worked out really well. This probably obfuscates the intent of the tests to an even greater degree, but I agree with Darrell that it's a small price to pay.

About small fixtures, I think this should be a best practice, if it's not already. One thing I wish I'd done was reduce the number of tests per fixture. Especially when using TestDriven.NET and "Test w/ Debugger". If I had 20 tests in a fixture, test w/ debugger would test them al. I'd have rather tested fewer if I had to resort to the debugger.

All in all it was a great experience, I identified lots of dead and broken code, and now have a good baseline for refactoring.

Thanks James!

re: Refactoring: Introduce SetUp Method

Brendan Tompkins — Tue, 16 Nov 2004 15:30:00 GMT

Tony,

I don't think that's entirely true. If you name your method Test(something) then, yes, it will be loaded into NUnit, regardless of the [Test] attribute. But to me this is just a feature of NUnit. Using the attribute seems like it's a much better way to write a test.

re: Refactoring: Introduce SetUp Method

Tony Chow — Tue, 16 Nov 2004 15:35:00 GMT

Actually, my bad, all my test methods are prefixed with the words "Test", and therefore would not need the TestAttribute.

re: Refactoring: Introduce SetUp Method

James Newkirk — Tue, 16 Nov 2004 16:36:00 GMT

I was reading the release notes for the next version of NUnit and I see that it will become a configuration option to recognize methods by name (i.e. "Test") as opposed to the attribute.

re: Refactoring: Introduce SetUp Method

John Watson — Wed, 17 Nov 2004 22:01:00 GMT

I did what Brendan mentioned above as well. I took it a step further and have testSetup and testTearDown stored procedures that are invoked from the base UnitTest class' Setup and TearDown methods. testTearDown truncates tables and uses DBCC to reset the identities to 1. testSetup (hard coded right now) does a bunch of inserts to various tables.

The net effect is that before each test is run the database is in a known, clean, predicatable state. Each project has a different DB schema and such so each testSetup has to be unique and different.

re: Refactoring: Introduce SetUp Method

Robert Angers — Tue, 07 Dec 2004 17:58:00 GMT

I think that Refactoring at all level should be applied. Eliminating dupblicate code is a goal every programmer should tend to, that for Production or Test code.

I belive that communication is an issue, but should not stop you from using it. It should be implicit that [SetUp] should be executed before every test. Since it not today common knowledge for everyone, does not mean we should not use it. It will become common knowledge. From that point on, the communication won't be an issue anymore.

It's like Design Patterns. Will you not use them because not all programmers know them? Of course not. The strategy is to use them and transmit the knowledge to your team.

James Newkirk s Blog Refactoring Introduce SetUp Method | Outdoor Ceiling Fans

James Newkirk s Blog Refactoring Introduce SetUp Method | Outdoor Ceiling Fans — Sun, 31 May 2009 18:15:43 GMT

PingBack from http://outdoorceilingfansite.info/story.php?id=2413

James Newkirk s Blog Refactoring Introduce SetUp Method | Outdoor Ceiling Fans

James Newkirk s Blog Refactoring Introduce SetUp Method | Outdoor Ceiling Fans — Sun, 31 May 2009 21:20:47 GMT

PingBack from http://outdoorceilingfansite.info/story.php?id=20049

James Newkirk s Blog Refactoring Introduce SetUp Method | home lighting

James Newkirk s Blog Refactoring Introduce SetUp Method | home lighting — Fri, 19 Jun 2009 08:30:44 GMT

PingBack from http://homelightingconcept.info/story.php?id=1589