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?