Can we rationalise our test data classes?

[tdwright]

Currently we have four classes in the ConTabsTestData project that exist solely for the purposes of testing and demoing:

1. DemoDataType
2. TestDataType
3. MinimalDataType
4. InvalidTestDataType

This seems like too many. (And we're proposing another called DemoAnimals in #21)

It seems to me that at most we'd need one for testing, one for demoing and one that's invalid. We may even be able to collapse testing and demoing into a single class.

Can we make a list of things that would be useful in each scenario? Once we've done that, we may be able to rationalise this list into a smaller one, which will be more lightweight and easier to maintain.

[rahl0b10]

Yes, good point. I think we can wrap up a few of those and then use a repository pattern to instantiate a list of data that can be used to create a table. At first glance, 1-3 can be consolidated. Just need enough properties to demonstrate all of the current and planned API features.

• Hide columns
• Reorder columns
• This brings to mind, I feel there may be a need for the API allow columns to be renamed, which would be useful in cases where a public field may have a long name. So, perhaps that should be considered in the rationalized test data classes.

I'm not sure if we can do the same with #4 though. It's explicit purpose is to be invalid via having only properties that are not accessible in the API.

[tdwright]

Completely agree re number 4. For the others, I think consolidating them into just one type is a good ambition.

Off the top of my head, the following types would be useful as columns:

• String
• Int
• Float/double/decimal
• DateTime

The numbers and datetime are useful for demonstrating the format string capabilities. It feels like having more than one string column (I'm thinking ahead to features like string transforms and overflow handling.)

What will make this complex is re-writing the tests to match the updated type(s).

Random questions:

• Is it useful in some situations to have a minimal data type as well as a more complete one?
• What theme should the data be? Animals? Planets? Something sporty?

[rahl0b10]

I agree with those columns.

Regarding the random questions:

• For the minimal data type, I'd argue that if there currently isn't a use-case for it, it's probably not worth making at this point.
• If I get a say and I were looking to make it fun, I'd probably theme it for something like a multiplayer video game where the object represents a player and the properties a number of personal descriptors and statistics. May even allow for some cool demo features, e.g. I know for Starcraft II there are several sites that have API's with replay stats. So, when people run the demo they'd get up to date stats on SC2 players. But, having not really considered it prior to your mentioning it, I really like the concept of planets as well.