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.

12/19/2024

At the start of the semester, we were introduced to Design patterns. These techniques include anything from completely restarting a project to erasing redundancy such as repetition of code. Our biggest focus was to use overrides ONLY where needed and it was our job to figure that out because there were certain methods that did need to be overridden.

We worked on a Duck Simulator that has methods for each duck itself, but some ducks needed functions to be overridden were as some didn’t need them for example a decoy duck does not fly. Whereas a mallard duck does therefore there is no need to override a function for that decoy duck. This design pattern is very easy to overuse specially for people not introduced to these types of problems.

The interesting part of this homework was also using the previously covered topic of UML diagrams. This homework though was more about reading and understanding but the main point was to transfer it to Java code. This was a nice intertwining moment because it makes it easier in the future to understand not just the UML but also the design patterns taught.

We created two different interfaces for the Duck Simulator which one was a Quack() and the other was Fly(). These made it so we as the developer do not have to keep overriding. Hence, we end up with a bit more files, but it saves us the trouble in the future if we needed to edit let’s say the decoy duck to fly. Now we are able to go into one file and edit without having affected any other files. Which in larger systems can become a big issue because now the developer has to go into every single file that uses said method which waste time and can be missed if multiple people are working on it at the same time.

We also learned about the singleton method which just retrieves a single instance of an object and if it is not there then it creates it does not use multiple of the same object. There is one down side I read about in the source and it was about unit testing. The source talks about many unit testing frameworks that rely on inheritance when producing a mock object which is a problem because the singleton class is private, and static methods cannot be overridden. Overall, it is still applicable, and we used it in the intermediate part of the design patterns homework to learn how it worked better to always only have one instance of a method.

Source: Design Patterns in Java

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

12/18/2024

At the beginning of the semester, we started to work with UML diagrams. We talked about the different types of diagrams and how each is written in plantuml. We started with UML class diagrams which show each files relationship to one another. It also shows the multiplicities which is important to know when, for example making an appointment. For example, only one person can have multiple appointments, but not multiple people can have the same appointment.

We also learned about Sequence UML diagrams which look different but have the same idea behind them. This type of diagram shows the method and its parameters in a sequence, hence the name. It shows how each class will be used whereas the class UML diagram just shows what the method name is and what the parameters for that specified method are as well.

The sequence UML shows the overall order of things whereas the class UML shows the general method and parameters that will be used. Both diagrams could be used on their own but help a lot more to be organized when used together. UML is very important to be able to visualize code without having to read over every single line trying to understand it all. It helps especially if working in larger groups for everyone to understand. There is another type of diagram that we didn’t talk about but is used a lot which is” use case diagram”. This diagram shows functional requirements, for example someone shops and the diagram show the possible actions the user can make. Such as view items or purchase more, but then behind those actions are more possible actions that can be taken like checkout or just cancel purchase. There is also activity diagrams that need to fill in a condition whether the use input the number in the right format or not. If the user did not then it throws an error, but this is all a visual representation of what the code is supposed to look like and be as well.

 UML diagrams have taught me to be organized in my own coding projects with visualizing my functions and the parameters I will be using. It also organizes file management when using the class UML diagram along with showing multiplicities. Even using other UML diagrams that can organize different parts of the same code and show how it will be used for example combining the class and sequence UML diagrams is a great way to use both for not just visualization but also organizing it all for a final product.

Source: Unified Modeling Language (UML) Diagrams – GeeksforGeeks

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

11/23/2024

In class this week we continued to learn about REST APIs, but this week we dove deeper into the source code. We went over the javascript files in the source code, and we also looked at the .yaml files.

We took a deeper look into the path endpoints in each endpoint file while looking at what each method asked for. Such that getGuest() for example had to make a request and also get a response. This method actually utilizes the “body” as a parameter to return a response. Whereas getOne() uses “param”, this is because when the endpoint needs a specific parameter to search, alter or even delete it will utilize wsuID as a parameter. Whereas the getGuest() retrieves all the guest which are stored in an array which will mean using “param” as our request will not work because we are not searching for one specific wsuID, but we want all the wsuID’s to be returned hence why “body” is used when sending a request.

We also learned how the mount-endpoint file did not need to be altered due to it just handling each endpoint the same. The endpoints only needed to be changed or added onto the endpoints path instead of the lib path. This is because they are handled the same way, but each do different things, hence why just adding a file to the endpoint path will be the best thing to do and nothing else would need to get done since the endpoint-mount already accesses the endpoint directory.

Also reading the article below showed me how the tags must be limited to those allowed by the JSON schema ruleset. It also shows how paths work in a sense such as /guest/{wsuID} which we also went over in class. If a wrong letter is entered it will return an error code either 400 or 404 depending on what the user’s input is. There is also for every method whether it is GET or CREATE endpoints each endpoint will have a wait method to check with the database if the wsuID is already in the database or not and if it is not then it will create it. Every endpoint also needs a method and a path then the body of the object, but it needs to be written in a try catch statement. This is very important due to feedback purposes for testing and such that if the server is down the user will get a 500 code or if everything is working well and the user inputted the correct information the code would be 200 or 201 depending on the method called. Each response code should return a message as well as what the error is for it to be identifiable. This is needed for each endpoint regardless of the case.

Source: OpenAPI Specification – Version 3.1.0 | Swagger

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

11/16/2024

REST is a crucial topic in APIs in which I just began to learn about this semester. Before this, I had never heard of REST API so I assumed it would be a challenging concept to grasp since I had no prior knowledge regarding this style.

This text dives into the definition, explanation, and exploration of what REST is, how it is used, and how we can get the most out of it in certain services. The text highlights the importance and nuances of REST API’s while still idolizing their importance of implementation.

Initially, during classes I found the material hard to grasp since I had no idea as to what Rest was and how it worked. However, everything began to make more sense when we started working with the hands-on assignments involving actual API calls.

I learned that with certain API calls you are able to retrieve, post, edit or delete information from the backend. These important methods are called HTTP methods which play a key role in manipulation, addition, or removal of information.

A couple key concepts that I learned based off of the reading are that REST APIs are cacheable, which are essential for improving performance and managing network traffic due to its cache technique. The reading also gives insights into how API’S are considered a layered system, in which it allows you to add proxies and gateways. These are very important concepts to keep a mental note on for the future as working in a frontend environment, especially when accessing backend data.

I expect to use these resources for building websites or even mobile applications, ideally when scalability and flexibility play an important role on what I am working on. I also learned that Resp API’s work alongside Node.Js and Express.Js. Node.Js is a back-end JavaScript runtime environment, while Express.Js is a web application framework for Node.Js. This relatively new information to me, due to my experience only using C++, Java, and Python for specific applications.

Rest API’s can be tested by integrating parameters and seeing how the output compares to the expected output, while also ensuring the correct error codes are being returned for methods like GET, POST, and others. The text also mentioned endpoints, and while I grasp the basic understanding, there is still more to learn in order to increase my confidence with this REST APIs Overall, I expect to use this knowledge and information in future jobs, as per my interest in software development, and in my personal projects. Additionally, I learned a bit more about swagger, which was introduced in class to demonstrate the GET, PUT, DELETE, and POST methods of the Rest API.

Source: The REST API Handbook – How to Build, Test, Consume, and Document REST APIs

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