Diagnostics Java code: Liar View error mode

Liar, liar!

Imagine that you've designed an excellent GUI program for a distributed system that contains everything the client requests and everything else. You have let it run through a test of an automated test suite--because the number of invariants is astronomical, automation testing is a must. The result of the test was that the program obtained a "Health certificate without errors".

It's time to publish this GUI, but as a strict programmer like you, just to discover the wrong behavior--the behavior that should have been captured in an automated test--you started the program and did the last manual test. I hope you can avoid this situation. Really, you can.

Liar View Error mode

Good debugging starts with a good test. Since there are a large number of invariants in GUI programs that need to be checked, automated testing is required. But sometimes, even though a set of tests have been passed, the program will still have the wrong behavior that should have been discovered by one of these tests when manually checking.

In distributed and multithreaded systems, this behavior is common. In these cases, the "uncertainty" nature of the program is often the cause. But in the GUI, there is another common cause ―liar View error mode.

Symptoms

Most GUI program tests, like the usual program tests, follow these steps:

Start Program

Check some features of program state

Attempt to modify state

Check that the status has been modified as desired

But as I've already mentioned, sometimes the result of a manual check of Run-time program behavior contradicts the test's successful results: A queue may appear on the screen that contains the elements that are tested (as intended) to confirm the deletion, and the object may contain stale data that the report shows has been updated.

Such a mistake would cause us to doubt the soundness of our mind or, worse, to Kant's philosophy of skepticism, and to doubt the validity of the reason itself.

Don't let this happen to you. It is really useful when you are dealing with the reason correctly. Despite negative reports, few programmers permanently lose their mind when writing code (permanently a keyword).

Cause

One key to finding these errors is to realize that at least some of the bugs can be found in the test suite.

In the process of testing GUI programs, the most common occurrence of errors is in the last step: check if the state has been modified as intended. The reason is that the GUI is generally designed based on the model-view-controller (MVC) architecture. Swing class libraries have even built this architecture into the GUI class itself.

In the MVC architecture, the internal state of the program is saved in the model. The view responds to events that change the state of the model and updates the screen image accordingly. The controller connects the two components together.

The advantage of this architecture is that the views are separated from the model so that their implementations can be modified independently. But it's a challenge for automated test methods: It's hard to see if state changes in the model are properly reflected in the view. When there is a contradiction between the two, we will encounter an instance of the Liar View error pattern.