In the previous week we spoke about Use-Testing which is a graph node with edges where the edges show the flow of the program, and the nodes are each line. These can be very big graphs if it is a large project but luckily, we can always shrink it down by taking out unnecessary nodes. This will also mean redirecting the edges correctly but after working with the full model it is much simpler to shrink it down. These graphs are called Decision to decision path graphs that reduce redundancy while keeping the important parts of the graphs still visible and with the flow of the program. These graphs go well with decision tables where it would be a True or False scenario with a “don’t care” option which can be used together with the path graph.

We also learned to define the paths by splitting the variables, defined at and used nodes into separate columns. This simplified things in order for us to assign the node number to the variable. For example, node 1 is numCells which is used in node 4 and 10, when we do this method, we can see where each variable is used at and therefore when we shrink our graphs, we know how to better organize it.

Overall, the use of the test cases helps us organize for test cases for the entire system. It helps us determine whether something is useful or not like an empty line can be counted as a node because the IDE is still going to check if there is code on that line, but for the final graph empty lines and else statements can be erased or shown as an edge. The graphs also help with noticing what we need for the test case not only what we do not need. This makes it easier to visualize the structure of the code while also easily being able to communicate what is required in order to make the test cases because the last thing anyone wants to do is write unnecessary test cases or and over abundant amount of test cases that should not be there.

Also, by using path testing you can easily visualize which node interacts with a certain edge or another node. If needed to explain to a team of engineers it will be easy and organized for anyone to look at while also having all the valid and important information that they need to create the test cases for the software.  I also learned about the cases that come along with these graphs which are cases 1-5 where case 1 is a node with no edge going into it which would always be the first node of the graph. Case 2 just does not go out to another node implying in some cases the last node. Case 3 would be an indegree greater than 2 and out degree greater than 2. Case 4 consists of 1 degree in and 1 degree out which is usually in variable declaration or in a sequential program. Case 5 is a single entry or single exit. These cases help to define the nodes further in-depth in order to dive deeper into the flow of the program.

Source: Software Testing – Use Case Testing | GeeksforGeeks

From the blog Cinnamon Codes by CinCodes and used with permission of the author. All other rights reserved by the author.

2/27/2025

This week we learned about Junit test cases. Coming from a C++ background it was a bit difficult to order my tests and to use one global object that runs before all other tests. In C++ the tests run in the order that you write them, and I learned that in java that is not a thing unless you specifically use order(N) N being the order number. This way of testing makes you able to order your test cases in whatever way you want. Also, I learned that you can just make a setup function with a single object and by using “Before All” this means the set up will run before any other test which helps with repetitive tasks of making objects over and over. I personally would rather create a fresh object for each test, but it was a nice experience learning that java just randomly tests and does not have an actual order unless stated otherwise.

Looking through the Junit 5 user guide when doing the homework I also learned that you can use “Before Each” for tests that you want to run before each test sort of like a for loop. One very interesting thing I have never encountered is that you can use lambda in order to compare variables using in objects. This makes it nice and compact for simpler tests because this can all be done within one line.

In class I also learned that gradle will give a different output for the test’s cases compared to vscode. I also encountered that when I would hit the checkmark in vscode for individual test cases they would pass and then other occurrences where they would not pass. Also, the same with running them globally all together. This confused me and took me a few hours to figure out why, but I realized it was due to my global object that I created. I also noticed that gradle would give me a different result as well, but it was much better and consistent than running the tests individually.

Source: JUnit 5 User Guide
Source: Writing Templates for Test Cases Using JUnit 5 – GeeksforGeeks

From the blog CS@Worcester – Cinnamon Codes by CinCodes and used with permission of the author. All other rights reserved by the author.