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 DataRow
class.
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?
Aucun commentaire:
Enregistrer un commentaire