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.

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.

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.