Wish: Add One-time Setup and TearDown methods

[mikepotjer]

It would be nice if the FxuTestCase class had methods like Setup() and TearDown() which would be called once during the life of the test class. They might be called OneTimeSetup() and OneTimeTearDown(), and they would be called at the end of Init(), and at the beginning of Destroy(), respectively.

These methods would be useful when multiple tests in a test class need to access the same read-only data, or some object that doesn't maintain a state. That part of the test environment can be setup once for all the tests in the class, rather than every time an individual test runs.

Obviously we could enhance the Init() and Destroy() methods of the test class directly. However, the Init() already inherits parameters and initialization code, which means that a future change to FoxUnit could break any test classes that override the Init() method. And although Destroy() currently doesn't contain any code, we run the same risk there.

[eselje]

One of the principles of TDD is the independence of each unit test. But rules are made to be broken.

On Tue, Feb 19, 2019 at 2:31 PM Mike Potjer notifications@github.com wrote:

It would be nice if the FxuTestCase class had methods like Setup() and TearDown() which would be called once during the life of the test class. They might be called OneTimeSetup() and OneTimeTearDown(), and they would be called at the end of Init(), and at the beginning of Destroy(), respectively.

These methods would be useful when multiple tests in a test class need to access the same read-only data, or some object that doesn't maintain a state. That part of the test environment can be setup once for all the tests in the class, rather than every time an individual test runs.

Obviously we could enhance the Init() and Destroy() methods of the test class directly. However, the Init() already inherits parameters and initialization code, which means that a future change to FoxUnit could break any test classes that override the Init() method. And although Destroy() currently doesn't contain any code, we run the same risk there.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/VFPX/FoxUnit/issues/21, or mute the thread https://github.com/notifications/unsubscribe-auth/AHy8TDgnpIN_kD1R1wCi4pK03l806A-cks5vPF87gaJpZM4bDzlp .

[mikepotjer]

Which is probably why NUnit, XUnit, and MSTest all support this. :-) https://xunit.github.io/docs/comparisons

[cwollenhaupt]

The test case class and a private data session are instantiated every time a test method is called. Init and Destroy currently fire for every test (and even every data point with the new theory support). xUnit has a test fixture concept which is a separate object that is assigned to every instantiated test object. However, this would work for objects only. It wouldn't provide shared cursors which are more likely to take a long time.

My first instinct would be that if the test setup is taking a lot of time, the test is either not a unit test, but an integration test, or it's testing more than a class. Most of my test use mocked objects and mocked cursors instead of actual tables. SQL Server access and web services run through mocked client objects that validate that the query is correct, but don't actually connect to the server.

[mikepotjer]

Sorry, Christof is correct. I've been studying TDD from Kent Beck's book and dotNET resources, so I ASSUMED FoxUnit worked the same way. But I wasn't thinking about data sessions, which Java and dotNET languages don't have. Since my suggestion won't work as described, I will close this issue.

I am also using mock objects and cursors, and testing a single class. But this is a 20 year old project which relies heavily on the Maxframe framework for various features. Performance isn't bad, but I thought there was room for improvement in areas where I have to work around a number of framework dependencies.

[eselje]

I appreciate how we talked this out. Keep those ideas coming!

On Thu, Feb 21, 2019 at 7:53 AM Mike Potjer notifications@github.com wrote:

Sorry, Christof is correct. I've been studying TDD from Kent Beck's book and dotNET resources, so I ASSUMED FoxUnit worked the same way. But I wasn't thinking about data sessions, which Java and dotNET languages don't have. Since my suggestion won't work as described, I will close this issue.

I am also using mock objects and cursors, and testing a single class. But this is a 20 year old project which relies heavily on the Maxframe framework for various features. Performance isn't bad, but I thought there was room for improvement in areas where I have to work around a number of framework dependencies.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/VFPX/FoxUnit/issues/21#issuecomment-466007323, or mute the thread https://github.com/notifications/unsubscribe-auth/AHy8TN2clN2rIqYvOZKNoQFo82Sbp2fTks5vPqTngaJpZM4bDzlp .