Author Archives: Joanna Presume

Learning More About REST API

I have been learning about REST API. There is UUID. It stands for Universally Unique Identifier. It is a combination of numbers that represent a user, keeping them anonymous. REST APIs adhere to the constraints of their RESTful architecture. They contain a base URL, a media type and standard HTTP methods like GET, PUT, PATCH, POST, and DELETE. POST creates new entries in a collection. PATCH updates a certain member in a collection. Think of sewing a patch in a part of a blanket. You can’t sew a patch over a whole blanket. GET retrieves (or gets) information of a collection or specific member. POST creates a new entry like making a post to add to the sea of posts online. PUT can replace a collection, replace a specific member or change an aspect about a member. There are also codes associated with the outputs of these commands. There is 200 which means that a command was executed successfully. There is 201 which means a POST has successfully created an entry. There are unsuccessful requests like 400 which means that the request itself has an error, 500 which means that the server could not do the request and 404 means that it cannot do what is requested. That is the bulk of what I know.

The main reason for the post is to learn more about REST APIs. I am using this website as my source: Debugging APIs Best Practices for Product Managers

This article seems to have more than the basics. Most of the other articles just go over what I know. This article goes over how to debug APIs. Debugging in general is a very important skill for any coding language. In fact, most of the time a developer spends on a project is debugging.

The main thing I learned were the steps to debug API. I am going to connect this with REST APIs since it is the API I am familiar with. Step one is to identify the issue. This can be done using developer tools like Chrome Developer Tools. I believe that this is for more complex work since someone could just review the REST API. The second step is just to check the status error code. The third step is just delving in further depending on the status error code. For example, I get a 400 error. I could ask myself am I misspelled something or if my input is not properly structured. Think about step two as gathering information and step three is looking through it. The last step is experimentation. Essentially, use problem solving skills.

Overall, this article gave me a better understanding of REST APIs. I knew a few of the steps beforehand so it was not completely new. It was nice to learn that there are tools to identify problematic API. I will keep it in mind if I ever need to use it. Maybe, I will use it in a future web application development.

From the blog My Journey through Comp Sci by Joanna Presume and used with permission of the author. All other rights reserved by the author.

Learning More About Design Patterns

Recently I have been learning about Design Patterns. I was specifically taught Strategic Patterns. It is a pattern that defines a family of algorithms, summarizes them, and then divides them up into understandable sections. In this type of pattern, there will always be at least one context connected to a strategy and a strategy connected to its subsections. This pattern also allows for choices in implementation which makes it perfect to have if your code needs to take any deviations due to a client. It is also good for anything that deals with a family of related algorithms, and anything that wants to avoid subclassing and conditional statements. This is good since conditional statements cause unnecessary nesting and put extra weight on the code and subclassing makes the code difficult to handle in the long run due to making it brittle. With this known, it is understandable why many utilize Strategic Patterns.

Now, I have demonstrated knowledge in strategic patterns but why stop there? There are many other pattern categories worth exploring.

To delve deeper into the topic, I used this website: https://sourcemaking.com/design_patterns

This website explains a few design patterns such as: Behavioral, Structural and Creational. It explains them in a beginner friendly manner, which is the main reason I chose it. It also defines what a Design Pattern is and the cons of using Design Patterns.

The first thing I learned about was Creational Design Patterns. This pattern focuses on class instantiation which allows you to use the blueprints defined by a class to create objects with specific states and behaviors. Let’s say you need to create a class that holds all existing employees. With class instantiation, you need to add is needed information such as name, email, department. Then, all you would need to do would be to give the employee attributes and the code would sort itself making sure that employee information would be sorted into the exact format you desire. In general, Creational Design Patterns specialize in making this a seamless process for your code.

The next thing I learned was Behavioral Design Patterns. It focuses on class objects’ communication. Sometimes one class needs information from another to initiate, terminate or do a specific task. Behavioral Design Patterns is designed for that. It possesses a chain of responsibility and makes sure each link in that chain runs smoothly. The code depends on it since if one class goes wrong, the others would follow.

To conclude, there are many ways to do Design Patterns. Each have their own purpose and specialties. It was interesting to learn about a few of them, and I wonder if I will have to utilize one in the future. Nevertheless, it was interesting to learn about.

From the blog My Journey through Comp Sci by Joanna Presume and used with permission of the author. All other rights reserved by the author.

UML in A Sequence of Learning Events

Lately, I’ve been having trouble with UML Sequence Diagrams. So, I decided to do further research to better understand the subject.

Due to learning about it in class, I have some prior knowledge about the subject. First, there’s the actor which is usually represented by a stick figure. The actor essentially acts as a user stand in. The rest of the classes are participants. Think of them as a path the actor has to walk across. The diagram shows the path that the code takes when the user executes the code.

I used this article for reference: Sequence Diagrams – Unified Modeling Language (UML) – GeeksforGeeks

It’s a beginner’s guide to UML sequence diagrams. It defines an UML sequence diagram and all vocabulary associated with it. It then informs how to one and the pros and cons of using one.

The first thing I started to better grasp was lifelines. I used to think lifelines were the solid lines but they depict an individual participant. Lifelines represent each instance in a sequence diagram. They are displayed in rectangles and go by their name and type. They are similar to actors but portrays objects internal to the system.

I also learned more about the messages. I knew that solid lines output messages and dashed lines returned them. I didn’t know that a solid line and a dotted represent synchronous messages and a single dotted line represent asynchronous ones. Synchronous messages wait for a reply before the interaction can move forward. Imagine if to people were moving boxes to a truck. Person A hands a box to Person B who puts it the truck. Person A must wait until Person B signals that they are done with their task. On the other hand, asynchronous messages don’t need to wait for a reply so Person A would just hand Person B the box without waiting for a signal.

So, to summarize what I learned. the diagrams are just a different way to demonstrate the code. It’s a communication tool between developers, managers, stakeholders, project managers and clients. It’s like a blueprint that anyone can look over. Clients can look over the plans without getting confused and make edits if necessary. Developers can take the blueprint and convert it into actual code. UML diagrams contain an actor that takes the role of a user engaging with the code. The participants represent the rest of the classes. The vertical rectangles represent the duration of a class’s execution. The arrows, not participants as previously mentioned, represent the path the code takes. Think about everything as components of a map.

Overall, this further research deepened my understanding of UML sequence diagrams. I feel like this would help me with the homework assignment but unfortunately it didn’t answer all my questions.

From the blog CS@Worcester – My Journey through Comp Sci by Joanna Presume and used with permission of the author. All other rights reserved by the author.

Third Time’s The Charm

Hello! I’m getting closer and closer to graduation. Just this semester and one more! As usual I hope to learn more to further my knowledge of computer science. Soon, I’ll be working at a company! Anyway, expect more posts as I further document my computer science journey.

From the blog My Journey through Comp Sci by Joanna Presume and used with permission of the author. All other rights reserved by the author.

Boundary, Equivalence, Edge and Worst Case

I have learned a lot about Boundary Value Testing and Equivalence Class Testing. Equivalence Class testing can be divided into two categories: normal and robust. The best way I can explain this through example. Let’s say you have a favorite shirt, and you lose it. You would have to look for it but where? Under the normal method you would look in normal, or in a way valid, places like under your bed, in your closet or in the dresser. Using the robust way, you would look in those usual spots but also include unusual spots. For example, you would look under your bed but then look under the kitchen table. You are looking in spots where you should find a shirt (valid) but also looking in spots where you should not find a shirt (invalid). Now, in equivalence class testing robust and normal can a part of two other categories: weak and strong. Going back to the shirt example, a weak search would have you looking in a few spots, but a strong one would have you look everywhere. To summarize, a weak normal equivalence class test would have you look in a few usual spots. A strong normal equivalence class test would have you look in a lot of spots. A weak and strong equivalence class test would act similarly to the earlier two, but they would have you look in unusual spots.

Boundary value testing casts a smaller net when it comes to testing. It is similar to equivalence class testing but it does not include weak and strong testing. It does have nominal and robust testing. It also has worst-case testing which is unique to boundary testing. I don’t know much about it, so I looked online.

I used this site: Boundary Value Analysis

Worst-case testing removes the single fault assumption. This means that there are more than one fault causing failures which leads to more tests. It can be robust or normal. It is more comprehensive than boundary testing due to its coverage. While normal boundary testing results in 4n+1 test cases, normal worst case testing results in 5n test cases. Think of worst-case testing as putting a putting a magnifying glass on something. From afar you only see one thing but up close you can see that there is a lot going on. This results in worst case testing being used in situations that require a higher degree of testing.

I have learned a lot. I have learned about boundary testing and how it differs when it is robust or normal. I have learned about equivalence class testing and how it varies when it is a combination of weak, normal, robust or strong. I have also learned about edge and worst-case testing. This is another step towards my coding career.

From the blog My Journey through Comp Sci by Joanna Presume and used with permission of the author. All other rights reserved by the author.

Boundary, Equivalence, Edge and Worst Case

I have learned a lot about Boundary Value Testing and Equivalence Class Testing these past few weeks. Equivalence Class testing can be divided into two categories: normal and robust. The best way I can explain this through example. Let’s say you have a favorite shirt, and you lose it. You would have to look for it but where? Under the normal method you would look in normal, or in a way valid, places like under your bed, in your closet or in the dresser. Using the robust way, you would look in those usual spots but also include unusual spots. For example, you would look under your bed but then look under the kitchen table. You are looking in spots where you should find a shirt (valid) but also looking in spots where you should not find a shirt (invalid). Now, in equivalence class testing robust and normal can a part of two other categories: weak and strong. Going back to the shirt example, a weak search would have you looking in a few spots, but a strong one would have you look everywhere. To summarize, a weak normal equivalence class test would have you look in a few usual spots. A strong normal equivalence class test would have you look in a lot of spots. A weak and strong equivalence class test would act similarly to the earlier two, but they would have you look in unusual spots.

Boundary value testing casts a smaller net when it comes to testing. It is similar to equivalence class testing but it does not include weak and strong testing. It does have nominal and robust testing. It also has worst-case testing which is unique to boundary testing. I don’t know much about it, so I looked online.

I used this site: Boundary Value Analysis

Worst-case testing removes the single fault assumption. This means that there are more than one fault causing failures which leads to more tests. It can be robust or normal. It is more comprehensive than boundary testing due to its coverage. While normal boundary testing results in 4n+1 test cases, normal worst case testing results in 5n test cases. Think of worst-case testing as putting a putting a magnifying glass on something. From afar you only see one thing but up close you can see that there is a lot going on. This results in worst case testing being used in situations that require a higher degree of testing.

I have learned a lot in these past few weeks. I have learned about boundary testing and how it differs when it is robust or normal. I have learned about equivalence class testing and how it varies when it is a combination of weak, normal, robust or strong. I have also learned about edge and worst-case testing. This is all very interesting.

From the blog My Journey through Comp Sci by Joanna Presume and used with permission of the author. All other rights reserved by the author.

JUnit, Test, and Repeat

I’ve decided that I wanted to practice making more JUnit tests. I did well on my last homework assignment, but I feel like I still need more practice. It took me some time to do it. I may have to generate my own JUnit tests in the midterm so I would need to make them at a faster rate. Anyway, practice makes perfect so there is no such thing as too much practice.

For this post I will be using this website: Inheritance in Java – GeeksforGeeks

This website contains two examples of code but I will use the first one. The code does not allow for user input but I’ll be drafting tests as if it does.

Before I write any test I would write:

import org.junit.jupiter.api.Test;

import static org.junit.jupiter.api.Assertions.assertEquals;

import static org.junit.jupiter.api.Assertions.assertThrows;

They will be useful later.

The first test I would make is a constructor test. I believe it should be one of the first tests. It is good to know the test works as it is supposed to since if it cannot do that it will need to be immediately revised. So, I would do this:

@Test

public void testMountainBikeConstructor() {

MountainBike mb = new MountainBike(30, 10, 45);

assertEquals(30, mb.gear);

assertEquals(10, mb.speed);

assertEquals(45, mb.seatHeight);

}

This is supposed to be take in three values and tests if the constructor initializes them correctly. I used the name “mb” because it was already in a class that was used to test inputs. It just made sense to me.

Another test I created tests the set string height method.

@Test

public void testSetHeight() {

mountainBike.setHeight(40);

assertEquals(40, mountainBike.seatHeight);

}

This tests if the height of the mountain bike can handle user input.

@Test

public void testMountainBikeMethods() {

mountainBike.applyBrake(5);

assertEquals(10, mountainBike.speed);

mountainBike.speedUp(10);

assertEquals(20, mountainBike.speed);

}

This tests if the mountain bike can speed up and brake.

@Test
void testToString() {
String expected = “No of gears are 6\nspeed of bicycle is 25\nseat height is 10”;
assertEquals(expected, mountainBike.toString());
}
}

This is supposed to test that the code has the expected output.

For the final test, I wanted to up the ante. What if I could test the limits of the code?

@Test

public void testSpeedLimits() {

MountainBike mb = new MountainBike(3, 100, 25);

mb.setSpeed(0);

assertEquals(0, mb.getSpeed(), “No negative speed!”);

assertThrows(IllegalArgumentException.class, () -> mb.setSpeed(-10), “No negative speed!”);

}

Overall, this was an interesting challenge. The main difficulty was finding the code to do this project on. There was code that was too easy thus difficult to generate meaningful tests on. There was also code that was too complicated which made it difficult to make a significant number of tests. In the end, it was nice to get some practice.

From the blog My Journey through Comp Sci by Joanna Presume and used with permission of the author. All other rights reserved by the author.

More JUnit

On my previous post, I stated that I was introduced to JUnit. I stated its definition, and a vast list of its annotation uses.

Now I have moved past that and started applying that knowledge. Last class, my group and I were unit testing with JUnit 5. We ran and made tests in the Rectangle class. We also ran tests using Gradle, which makes testing easier.

On that note I was looking through an article that gave me more information on JUnit testing. It is called: JUnit Testing Framework – A Comprehensive Guide | HeadSpin. It retreads on known ground but gives step by step guides on how to access and download certain things. One thing I can commend it for is the detail in certain parts of the blog. It feels like a more advanced version of the previous one like, the previous one would be used for a quick Google search while this one would be used for a step-by-step guide.

It also introduces new information such as debugging. I personally know barely anything about debugging. I have seen it but I never really understood its function. I remember in freshman year I assumed that it would aid in fixing coding mistakes so I tried it. Unfortunately, it did not do anything.

Now, how does debugging work in JUnit? There are two modes: Java Debug Wire Protocol and Standard Streams. Java Debug Wire Protocol is the one that is more likely to be recommended. It can be used broadly and provides a lot of information from test execution. In Standard Streams everything that would usually go to the main console window would be printed to the standard output stream. Unfortunately, this provides less information than Java Debug Wire Protocall so is better fit for simple tests.

I also learned some troubleshooting techniques for Java applications. I learned that one way to troubleshoot is to use log files or profiles to gather information about the application. Also when there are issues with libraries or testing frameworks, it is good to check their documentation and forums.

Overall, I feel like the article should have described more about debugging in JUnit. I feel like I got a good understanding of Standard Stream, but I do not feel like I fully grasped Java Debug Wire Protocol. The definition provided was not enough. Maybe because the article assumed the reader knows debugging and/or used it. I am not sure. Nevertheless, It was nice to learn more about JUnit. I hope to use it again in the future.

From the blog CS@Worcester – My Journey through Comp Sci by Joanna Presume and used with permission of the author. All other rights reserved by the author.

Just JU-nit

I was looking through an article called “What Is JUnit: An Overview of the Best Java Testing Framework”. The link is here: What Is JUnit: An Overview of the Best Java Testing Framework. This article introduces JUnit to its audience. First it defines JUnit which is open sourced unit testing for code in the Java language. Then it defines unit testing which is what JUnit is part of. Unit testing is defined to have the audience better understand JUnit. Although I personally would have put the unit testing definition before the definition of JUnit since it appears in JUnit’s I understand that it was done to get more traffic on the site. The article later list JUnit’s features and its annotations.

I chose this article because it related to what I have been recently learning. Also, I am new to JUnit so it would be interesting to learn more about it. In my most recent class, we were introduced to annotations which I defined as indicators for when a method should execute or is a test. Thanks to the article, I understand that an annotation can be used to ignore statements during test execution, to set some timeout while a test is executed and to handle some exception during test execution. I also learned about JUnit’s use cases. At first, I thought it only verified that the provided code worked. I now know it has a lot more uses. It tests how code behaves will null values and invalid data. It verifies that objects maintain their state throughout their lifecycles. This essentially means that it checks if objects do what they are supposed to do. It tests interactions between the tested code and the external library. It provides a safety net allowing users to not worry about regressions when modifying their code. Also, JUnit code is a cornerstone of TDD, integrate with CI pipelines and can run test legacy code. These lead to bug free and testable code. So JUnit has a lot of uses.

I also liked how the article was structured. It was simple, concise, and provided a lot of useful information as seen on the paragraph above. I only wished it gone over JUnit assertions because I am still a little confused about that. Overall, this was a very newbie friendly article.

To conclude, I this article has improved my understanding of this topic. It has also increased my interest. I look forward to learning more and using this in the future.

From the blog CS@Worcester – My Journey through Comp Sci by Joanna Presume and used with permission of the author. All other rights reserved by the author.

Round Two

Hello! I have returned to continue documenting my computer science journey. In this semester will be learning new things and new concepts that will further my knowledge of computer science. I hope to learn more about the business side of computer science and how software developers (or any other computer science profession) operate on a daily basis.

From the blog CS@Worcester – My Journey through Comp Sci by Joanna Presume and used with permission of the author. All other rights reserved by the author.