This week we started to work on our own POGIL activity similar to the Sir Tommy code review. The activity the team has chosen will be a dice game with a specification sheet that expects the people to do the activity based off of the specification sheet. The sheet is going to have specific questions asking what lines contain bugs or have format issues that are not best practice. This will help the students read code more in depth as well as to work together in searching for bugs and format issues. The team is going to meet out of school to determine the questions and how we will go about working on the project. We will also focus on the types of questions we are going to ask in order to make the reader think about what they are reading and to critically think about how they will address the issues presented in the source code as well as test code.
                We are thinking about making a few models explaining and asking questions that send the users to the code to examine it, but also think about much deeper than just the code they are looking at. We will implement Encapsulation, Inheritance and Polymorphism. This means that the users will have to read and understand underlying methods within other methods in order to progress through the models, but it still will be simple enough so that the users do not take up too much time and can focus on the questions rather than the code.

In class yesterday we talked about what other teams were doing, and it was very interesting that everyone took a different approach to the homework. I am still glad my group stuck with sir tommy due to underlying issues with the original that we thought was a good idea to add certain bits and pieces to make the activity more understandable. We did the model questions asking about stubs, mocks, fake and dummies in mind, we dedicated an entire model to these objectives so that the student would understand how each works and how to create and get rid of each for a more optimal solution.

                Overall, this activity showed me how much I learned about different types of testing how to read and understand certain aspects of other people’s codes as well as paying close attention to imports as usually you assume the imports are always correct. I also learned that I have been using dummies, fakes, stubs and mocks without knowing since I did not have prior knowledge to these types of testing. I really enjoyed the class as well as how it was structured and how we had to figure things out on our own as well as a team.

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

This past week we worked on test drive development which was very difficult for me do to me being used to working with only source code first then writing test code. This new approach in my head was fairly easy, but when I went to code it, I was struggling. I believe part of this struggle was due to me not thoroughly writing out my test cases and taking the time to fully understand what I was doing. I ended up doing better on the testing for the homework than the activity I believe because I took a step back to understand and read more in depth into the five steps provided. I decided to also read more on another website (sourced down below) about test driven development, which this website went into more of the process of it and how the cycle works. It explored the history of it as well as the advantages and disadvantages.

These advantages included how writing the tests first provided constant feedback to the developer as well as always meeting the requirements more in depth and not having unnecessary tests or codes. This helps developers decrease production time in some scenarios due to only having to write the tests than source code to only specially pass that one test and if needed down the road to refractor code the developer can do so as well, but they will know what went wrong and reach their conclusions much quicker. The disadvantages spoken about are increased code volume which can be a pain currently or down the line when the code is going to be refactored or maintenance. Also, a huge disadvantage that can lead to multiple issues is false security from tests which some developers will go in and assume since one test passed, they do not need to make more. I believe personally for larger applications test driven development is not the best idea due to ever growing projects which will require lots of testing and can only be written after the source code to ensure they all work together rather than individually because some methods rely heavily on other methods.

The great thing about test driven development though that I learned and enjoy is finding bugs much earlier on. It helps me quickly go back and refractor my code for the test to pass but as stated previously it has its advantages and disadvantages. Overall, I had a hard time with it because I have never heard of it until now, but reading more about it I understand the main concepts of it. The activities in class did help discussing with the team as well as the homework, but the thing that confused me about the homework was the log since I usually don’t write logs on how and what test I am going to do because I base it on the source code. Overall, it was a great experience, and I am glad I was exposed to it so I can try it more on my free time and see how it is used in the real world.

Source: What is Test Driven Development (TDD)? | GeeksforGeeks

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

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.