I have a basic class in C# from which I create inherited classes for databinding scenarios. You can think of it as a substitute for .NET's
I want to automate testing of a typical row's lifetime, making sure that things such as object state and changes detection remains coherent throughout.
My first thought was to simply use unit test class with a method that would do multiple operations and consequent assertions, like this:
/* For the sake of keeping this as simple as possible, let's just assume that new instances can be created with a public constructor, as "unchanged". */ var row = new PocoTest(); // Derived from aforementionned base class Assert.AreEqual(RecordStates.Unchanged, row.RecordState); Assert.IsFalse(row.IsPropertyModified("MyProperty")); row.MyProperty = "this is a new value"; Assert.AreEqual(RecordStates.Modified, row.RecordState); Assert.IsTrue(row.IsPropertyModified("MyProperty")); row.AcceptChanges(); Assert.AreEqual(RecordStates.Unchanged, row.RecordState); Assert.IsFalse(row.IsPropertyModified("MyProperty"));
However, this doesn't feel right in the unit testing paradigm in which it is recommended to have only one thing at a time being tested.
So I'm kind of looking for some advice, here. Am I overthinking this? Should I just keep doing it this way? Or is there another, better and more adapted way to accomplish something like this?