Write Test Script

Any coding for a business activity or entity has to be an abstraction at some level to the reality. That means it takes hold of some features that business people concern and neglects the ones that are not concerned.

From a broader sense, I would think a discrete system is an abstraction to a continuous system. I have seen a lot of math algrithms trying to get a continuous system representation from discrete systems, and the other way around, produce a discrete system from a continuous system by taking samples. Either way, it relies on a clear concern from people who conduct the task.

Object Oriented analysis methodology guilds us to abstract a matter in terms of attributes and behaviours. Some of the attributes that are exposed to outside, named properties specifically, mostly get concerned when writing test script, because they altogether represent the state of that matter. In complicated scenario, system designer needs to draw state machine diagram to clarify states and their transitions. To write test script for an activity, developer needs to suppose a precondition and expects a post condition in terms of state. After an activity is executed, test script checks the state. An intermediate state is treated as a failure of the activity.

Now that a test case is to check with an expected state, we need to have a clear understanding of states. A state is defined with a set of variables, S ::= {v1, v2, ..., vn}. The number of variables means the complexity of the state. It also means how many concrete states we end up get. As a result, states with large number of variables may be hard to handle in test script.

In this case, the state can and should be decomposed into hierarchical structure, then conduct test from the top level down to detail level. File Receiving test for example, I made the top level test only to check succeed or failure.