Notes for automatic write test in a state machine

Without a state machine, you can simulate the UI thread based on the customer's usage habits, such as click (), drag (), drop (), and so on, in this way, you don't need to write other functions, but just need to directly use some ready-made UI performances for simulation.

However, if the global state of your project is driven by the state machine, you should pay attention to it. If you simulate the UI action, there may be some events that the state machine cannot simulate-for exampleStatus jumpSuppose a-> B-> C. In this state stream, you are in the state, but because you use the UI function, a may directly enter C.

For example, if you use the UI function in the state, but you are not actually in the C state at this time, this UI function may be useless at this time.

Therefore, in the case of a state machine, to write an automatic testing script, you must follow the state machine route to avoid some messy errors, for example, you can follow the logic of postevent-> UI function.