Node_specification_unit_test

[xp1632]

My basic knowledge of testing is based on code:

• we expected a certain result and get compare the current result with expected result
• if it's the same, then pass, if not then fail.

---

However, can people do a unit test for GUI? Here are several answers by searching

---

Strategies for GUI unit testing:

1. Model-View-Controller (MVC) or Model-View-Presenter (MVP) Design Patterns: These design patterns aim to separate the logic from the GUI as much as possible. This allows you to unit test the logic independently of the GUI.

2. Testing Small Units of GUI Behavior: You can write tests for small units of GUI behavior. For example, if your application includes graphs, you might have functions that calculate different shades of a color based on a ‘base’ color. You can extract this calculation to a function and write a unit test for it.

3. GUI Testing Tools: There are tools available that can help with GUI testing. For example, pytest-gui is a GUI-based test runner for Python Unittests and py.tests.

4. Checklist-Based Testing: This involves checking all the GUI elements for size, position, width, length, and acceptance of characters or numbers.

[xp1632]

Intention for a GUI_unit_test for VP_Node_generation_pipeline

• is to test if the JSON node specification we get from pipeline could be a working Visual Node in VP project
• I am not sure it's in the scope of GUI unit test, we'll see after we finalize our thoughts

[xp1632]

Current existing unit test in Visual programming Language project

• I checked the existing unit test in VP project:

---

---

• The test is based on checking:

  • if we get expectation source code from the ${} formatted code based on assertion in nodeExecCheck
  • if this code could be executed in Conda python environment without stderror

[xp1632]

What we need to solve

• Testing that if the source code is executing in the conda env without std err is a good idea
• However, during 30 times of testing or making a manually modified Node specification work, I met the following cases:

---

Sure case:

1. We can not Add Node into VP project
   • when clicking on the node on the search menu, nothing happens

Not so sure case

2. The source code is correct, but the node is not working

---

What I want to say is:

• if this source code checking is enough for checking if a JSON file could be a working Visual Node in VP
• if not, what do we lack here?

[xp1632]

Behavior-driven development

• While learning refactoring, I get to know the term BDD, Behavior-driven development https://en.wikipedia.org/wiki/Behavior-driven_development

• this method test the software by desired behavior

• one short example of desired behavior:

---

• A description of each specific scenario of the narrative with the following structure:

Given: the initial context at the beginning of the scenario, in one or more clauses; When: the event that triggers the scenario; Then: the expected outcome, in one or more clauses.

---

- A more concrete example for our pipeline is :

Given : user input the information we need for one visual node specification: correct code snippet to run it, op name, input name, output name When: all information is feed into pipeline v1 Then: the specific information is extracted and formatted, and output the final visual node specification

---

- Main Purpose of this Pipeline v1.0

• This eliminate the repetitive tasks of copying and formating information to fit the Visual node json specification that VP project needs

• This Pipeline v1.0 makes sure accuracy since we have most accurate information (the code snippet of calling an op)

- Fei's proposal's Pipeline v2.0

• However, Fei proposed to make this pipeline batch for 100 nodes

• based on BDD, I can roughly describe his desired scenario

Given: user inputs nothing, we get everything including the code snippet to call the plugin from a library, When: we process the information from library's every method Then: we get a batch of visual nodes for VP project

---

Again, this batch method could be working, but the cost is the robustness of if this node is functioning when we generate it by a uniformed code snippet, while the op callings in ImageJ itself is not quite uniformed