Category Archives: Computer Science

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.

Another Look Through Someone Else’s Code

On my last post I looked through an independent developer’s code. It is messy so I applied clean code principles to it. Unfortunately, I only made a few fixes. There was a lot to say. Now, let us take a second dive into the rocky waters known as this developer’s code

Just to note, I will continue to use an uploaded replication of his code from GitHub:GitHub – LordEnma/YandereSimulatorDecompiled: Decompiled Code from the game Yandere Simulator.

The first thing I want to jump into is the Timer.cs file. It is part of the minigame where the player works in a cafe to make in game currency. The minigame is timed. It starts when the player presses start and when it runs out the minigames stops, calculates the in-game money earned and gives it to the player. One fix is to change the function named “Awake” into “GameTurnedOn” or “GameBegin”. Awake is supposed to tell the file that the player has started the game. The name given makes no sense since there is no sleeping in this minigame.

The next thing I want to discuss the ServingCounter.cs file. It is part of the cafe minigame. The counter is where the player sets their empty tray and picks of their tray filled with food. My first fix is to remove chefMask and trashMask from the SetMask function. Next, change Setmask to “SetservingcounterMask”. The whole file pertains to the serving counter. The chef AI and trash can should not be affected. It would be better to put something that could call on a function. Then the functions in their respective files would execute.

The next thing I want to discuss the KnifeDetectorScript.cs file. The whole thing is a mess. I think this sees if the player has a knife but it includes code of hiding a knife and interacting with a blowtorch. Maybe the code is for the player heating the knife with a blowtorch. Firstly, the name of the file is bad. It does nothing to describe what the code is doing. It is better to name the file “HeatingKnife”. Second, blowtorch is a bad name in general because the item looks exactly like a Bunsen burner. This has to be renamed to Bunsen burner. Lastly, why does the file mention a knife but the code does not specify a weapon? This would be confusing for anyone jumping into the code. Either change the code to only mention knife or change the file name to “HeatingWeapon”.

I have the same thoughts as the ones in my last post. The code is messy and any outside party trying to change it will have a lot of trouble. I also learned something new: the importance of naming things properly. Coding without proper naming is like trying to put furniture together with no labels. Even if you put to pieces together you run the risk of putting the wrong pieces together, getting them stuck and wasting time trying to fix it.

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.

Looking Through Someone Else’s Code

Recently, I have been learning about clean code. It is a way of coding that prevents cluttering and confusion which is very important since coding is a collaborative effort. Without clean code mistakes would be constantly made, time would be wasted trying to understand each teammates code and most importantly nothing would get done.

It got me thinking about a developer. He’s infamous for his poor coding skills. It has gotten so bad to the point that he was wasted years coding one game even with volunteers’ aid. So, I would like to use my newfound knowledge to see how bad his code is and offer ways to clean it up.

I will be using an uploaded replication of his code from GitHub:GitHub – LordEnma/YandereSimulatorDecompiled: Decompiled Code from the game Yandere Simulator.

There are many parts of the code that need to be fixed but I will start in the ActiveAnimation.cs file. It dictates when a game cutscene is supposed to happen. One thing that stands out to me is the void function play. It contains a lot if statements (10 in fact). First, play is a vague name. It does not clearly explain what the code does. One can conclude that it plays the cutscene but there’s already a function that does this. Second, this function should be separated into smaller functions. One could play the cutscenes. Another could adjust animation components. Another could allow for earlier execution which would get rid of the else if statements. The computer would go, these conditions are met execute this or another set of conditions are met execute that. It would also make changing code easier which tends to be a problem for the developer.

Next, I want to discuss the AIControllers.cs file. It is part of a minigame where the player works in a cafe to make in game currency. Looking at the name one can assume that it only deals with player controls but that is not true. It also controls nonplayable characters which does not make sense. If something goes wrong with the nonplayable characters, it will be a pain to find where their code is. It is a little amusing since there are two files for the chairs of the minigame and all they do is move left and right. The main fix would be to take out the nonplayable characters’ code and put it with the chairs’ code since they both rely on each other. Overall, this file seems to be an improvement from the previous one but in general it should just focus on player controls. Remove everything else and put them in their own files.

To conclude, I understand why this game is taking a while to complete. From looking at two files one can see that the code is a mess. I think the developer and his volunteers should stop and focus on organizing the code. So in the end I learned one thing: do not code like this developer.

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.

Scrum: Is it really that bad?

I was reading an article called “Why Scrum Fails” by Jason Godesky. The link is here: Why Scrum Fails | Better Programming. It is pretty a list of much all the pitfalls Scrum contains. The author lists many points for why Scrum is not a good wat to achieve Agility. He criticized the increments saying that they do not focus on customers and giving working software. He then criticizes self-managing teams by saying that managers can interfere. They could see their positions threatened, since there are no managers in scrum teams, and try to squeeze themselves into teams. Managers may try to take management task from the developer’s shoulders as a good gesture but in actuality they take away the team’s autonomy. No one is willing to just give up their role in the company. The author also mentions a “monkey’s paw” situation where companies that want to have a quick and painless way to improve output get it and later stunt the company growth. This is mainly because companies refuse to use Scrum to transform the company but instead delegate it to a developer only thing.

This made me think of what I learned previously about Scrum. I thought it was a structured and reasonable process. First there is the Sprint where ideas turn to value. Then Sprint Planning to plan for the work that will be done. Then the Daily Scrum which acts as a progress report. After that the Scrum Review which inspects outcomes and determines future adaptations. Finally, Review Retrospective which plans for the future. All of this seems reasonable. Although, after reading the article I can start to understand the criticisms. There is no role for the managers. But to counteract this I want to add that the managers could just become Scrum Masters. Maybe the role could be divided into two and have middle managers be involved. Also, there is no focus on working software but that could be added to the Definition of Done. Easy fix. To be honest it is strange to be introduced to something as a positive and helpful and then to immediate learn that it has so many faults.

To conclude, Scrum is not perfect which makes sense since it is man made. Also, a lot of the problems in Scrum is just how the companies enact it. For example, one critism was that Scum is mostly limited to developers and not companywide. Still there are still flaws. Nevertheless, I still think it is relevant to companies and would like to use it in the future. Overall, Scrum is not scum.

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.

I Learned Something New

I was reading about the top four symptoms of bad code, and it reminded me of the classwork I did earlier today. At that time my group and I were learning about the Waterfall Methodology and the Agile Methodology.

But first, the article’s link is this: Top 4 Symptoms of Bad Code – Excella. To summarize, it lists rigidity, fragility, immobility and viscosity as symptoms of bad code. Rigidity makes code difficult to change and causes non rigid problems to stay unfixed. Fragility is when software breaks when it is changed. To simplify, it causes the common issue of when one bug is fixed and multiple spawn in its place. Immobility is when software can’t be reused which leads to code having to be duplicated. Viscosity is when the developer is hesitant to change their code. This can result in wasted time and energy.

Back to what I was saying earlier, this article made me think about how the symptoms of bad code would affect the development process under Waterfall Methodology and the Agile Methodology. Under the Waterfall Methodology, rigidity and fragility would delay the verification and maintenance process. Rigidity makes code hard to edit which would make the steps where a person would have to edit code especially difficult. Fragility would cause time to be wasted or worse, it could delay the whole project. Immobility would delay the implementation process since time that could have been spent somewhere else is being used to duplicate a piece of code. Viscosity has the potential to affect the deployment stage since it could allow a program with bugs to be sent to the customer. Think about how some video games tend to be published with bugs. If only one or a few developers suffer from viscosity, then it would only delay the verification and maintenance process.

Since the Agile Methodology is more fast paced any delay would be more significant. Rigidity, fragility, immobility and viscosity would all call delays or a rushed project that may not meet up to the customer’s expectation. Viscosity would allow problems to fall through the cracks. Immobility would waste precious time. Fragility would take away attention from coding and push it toward constant bug fixing. Rigidity would extend the time it takes to fix bugs.

Overall, I believe this article achieved two things: teaching me something and allowed me to make a connection to what I learned earlier. I liked that it was short, to the point, and easy to understand. I will use this information to recognize when I fall into this pitfalls and course correct in school and my future career.

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.