Week 4 exercise 3

Retrieved from SWE 437 In Class Exercise #5 JUnit. Code available in the end of the blogpost.

Question 1

Given the 4 @Test methods shown, how many times does the @Before method execute?

Just one time, it will setup the environment for the class we want to test.

Question 2

The contract for equals() states that no exceptions may be thrown. Instead, equals() is supposed to return false if passed a null argument. Write a JUnit test that verifies this property for the EH class.

@Test public void noNPE() {
assertEquals(false, eh1.equals(null));
assertEquals(false, eh2.equals(null));
}

Question 3

Using the given EH objects, write a test that verifies that equals() returns false if the objects are, in fact, not equal.

@Test public void equalsFalse() {
assertEquals(false, eh1.equals(eh2));
assertEquals(false, eh2.equals(eh3));
}

Question 4

Using the given EH objects, write a test that verifies that equals() returns true if the objects are, in fact, equal.

@Test public void equalsTrue() {
assertEquals(true, eh1.equals(eh1));
assertEquals(true, eh2.equals(eh2));
assertEquals(true, eh3.equals(eh3));
}

Question 5

Using the given EH objects, write a test to verify that hashCode() is consistent with equals. This test should fail if hashCode() is commented out (as shown), but pass if hashCode() is implemented.

@Test
public void hashConsistent() {
assertEquals(false, eh1.hashCode() == eh2.hashCode());
assertEquals(true, eh2.hashCode() == eh2.hashCode());
assertEquals(true, eh3.hashCode() == eh1.hashCode());
}

Code repository

4 of 4 test passed

https://github.com/samosunaz/wa-integration/tree/master/activities/week4_chapter3

Chapter 3 Team Exercise

Why do testers automate tests? What are the limitations of automation?

Because it reduces the cost of testing and human error, also it makes regression testing easier because it allows a test to be run repeatedly. Excise tasks are candidates for automation.

Although this is an essential process, it has limitations:

  • Continuous adjustment to testing code
  • Cannot be used for testing UX
  • Script reliability depends on programmer
  • Requires silo elimination

How the inheritance hierarchy can affect controllability and observability?

Having a deep inheritance tree of classes could become more complex to test, because the sub classes are dependent of its father, that means, if we modify or update something in the super class, it will affect all its respective children, which means that every test affected by the modification have to be updated for the sub classes. Therefore, inheritance does not guarantee that a method tested in the context of the super class will work correctly or in the same way that in the context of the sub class or sub classes. Thus, this affects controllability because we will need to control every super class and its sub classes, and if wee have a deep inheritance tree, it will be very complicated. On the other hand, it affects observability becase we need to observe a large number of sub classes that actually are doing the same work as the super class.

Develop JUnit tests for the BoundedQueue class.

You can find the code here.

Delete the explicit throw of NullPointerException in the Min program. Verify that the JUnit test for a list with a single null element now fails.

If we delete the line

if (result == null) throw new NullPointerException ("Min.min");

We can see that the test testForSoloNullElement() fails.

6. Consider the following example class. PrimeNumbers has three methods…

(a) A test that does not reach the fault

 @Test
void testComputePrimesA() {
PrimeNumbers primeNumbers = new PrimeNumbers();
primeNumbers.computePrimes(0);

assertEquals("[]", primeNumbers.toString());
// it never enters the while loop
}

(b) A test that reaches the fault, but does not infect

@Test
void testComputePrimesB() {
PrimeNumbers primeNumbers = new PrimeNumbers();
primeNumbers.computePrimes(7);

  assertEquals("[2, 3, 5, 7, 11, 13, 17]",
primeNumbers.toString());
}

(c) A test that infects the state, but does not propagate

 @Test
void testComputePrimesC() {
PrimeNumbers primeNumbers = new PrimeNumbers();
primeNumbers.computePrimes(8);

assertEquals("[2, 3, 5, 7, 11, 13, 17, 19]",
primeNumbers.toString());
// it is affected because it doesn't include 19
}

(d) A test that propagates, but does not reveal

This test is not possible because the faults starts at the 19 (we’re not taking in consideration 9, because it is not prime), all of subsequent primes that ends in ‘9’ won’t be in the result value.

(e) A test that reveals the fault

@Test
void testComputePrimesE() {
PrimeNumbers primeNumbers = new PrimeNumbers();
primeNumbers.computePrimes(8);

  assertEquals("[2, 3, 5, 7, 11, 13, 17, 19]",
primeNumbers.toString());
}

Exercise 7.

The computePrimes is now using the Sieve of Eratosthenes to find the primes. The first false positive result is again 9, it doesn’t print it, to reach the fault it has to compute the first 7 prime numbers. The RIPR model should be used to know if there’s a fault in our system, on the contrary, we could think that our program is running correctly, but we have so many false positives waiting to be propagated.

JUnit and Intelli-J (mac os)

What is Intelli-j? it is basically and IDE for software development, its first release was in the year 2001. It was developed by JetBrains and it’s not based on Eclipse. But i’m pretty sure you aren’t here for this but to to learn how to do a basic setup for J-Unit and Intelli-j community edition. Here is what you’ll need:

  • Mac Os X 10.5 or superior
  • 1GB of RAM as minimum.
  • JDK 1.8

The steps to follow can be found in the next video:

Quick configuration video

If link is broken go here: https://www.youtube.com/watch?v=Z8V7rnvDeB4

Detailed configuration setup video

Link: https://www.youtube.com/watch?v=6k-AA1uR5jY&feature=youtu.be

In general IntelliJ and JUnit 5 configuration is really simple. Mostly because a lot of the Maven integration is done automatically by IntelliJ. So if your goal is to learn how to set up Maven into a Java project, this is not the best method. But if you are looking for simplicity this is a very good choice.

Git repository: https://github.com/kevintroko/JUnitTest

JUnit 5 documentation:https://junit.org/junit5/docs/current/user-guide/

Test && Commit || Revert ?

About two weeks ago I started an internship in a Software company. They like to use this relatively new framework known as Agile. But it isn’t only used where I work, it seems that a lot of companies are trying to migrate to an Agile approach (or some kind of distorted version of it 🙄).

In other words, they like using the SCRUM mindset.

In other words, Ken Beck has influence my work days and probably a lot of many other people.

So after doing a lazy Google research I found out that the Agile roots (extreme programing) were mostly developed by a smart guy named Ken Beck. He did not just worked on this awesome methodology, but also contributed to Test driven developmentSmalltalk, helped popularized the CRC cards along Ward Cunningham, and made the unit testing framework JUnit. It’s incredible all the work this guy has contributed into the Software industry.

Kent Beck (right image) Was one of 17 authors of the Agile manifesto which shaped the constant changing software industry

So what about TCR?

Kent Beck proposes: TEST && Commit||Revert which basically consist in:

If my test pass then I want to commit it!

If I fell that something wrong happened in my code then I can go back to the last time it worked. Therefore, the incentive is to make small changes, all in a stable way. It’s better to have many smaller commits than a big commit with all the different changes.

This doesn’t mean you will have to write more tests. But if you are going to make 3 tests at once maybe it’s better to test one by one so the code of the 3 don’t fully disappear. As Kent Beck says:

How could you make progress if the tests always have to work? Don’t you make mistakes sometimes? What if you write a bunch of code and it just gets wiped out? Won’t you get frustrated?

Kent Beck

And yes, the mistakes will be made, we are humans and the human factor will never assure to have working code 100% of the times. But it is better to instantly wipe out all the bad code. So if you don’t want for big chumps of your work to be sent to the forgiveness then don’t make really big commits between the successful tests.

I guess most of us, university students that hadn’t finish a Testing course, program either by submitting the whole code project until the end, until it’s working as a whole. I’m not counting much the team projects because we commit occasionally, but, it’s a different reason. I think we commit to share code, not to have it safe for testing. And even deeper I guess we don’t do any formal testing.

TDD vs TCR

Test Driven Development: Also created by Kent Beck (is there anything this guy can’t do?), is basically a programming practice where you have to write test first and then write the code that will pass it. Finally do a refactoring.

I don’t have a lot of experience with TDD to be honest. To be even more honest I wasn’t even sure about what it really meant. I guess my testing before this class was running a program, if something goes wrong fix it. And occasionally throw as many weird inputs to see what happens. But I want to change this. Maybe TDD is the solution, maybe not.

TDD workflow

Test Commit Revert: It’s an alternative workflow. TCR is chaotic in a sense that there will be different problems. Maybe TCR will be very weird in Github. To have a lot of tiny commits, for 12 line of code seems incorrect. But there are some solutions as squash commits. If all test passes then commit to master, if anything fails use the the revert button, Life is too short for waterfall planning.

References

You can read the whole Agile manifesto (all along the early 2000’s web pages experience) in here: https://agilemanifesto.org .


First Personal Post 2.0 #TC3045

Image taken from Diyfail.com

Hello my name is Kevin Oswaldo Cabrera Navarro. In the next 3 months I’ll be writing about Software testing, verification and quality. So why does Testing and quality matter?

Quick example of why quality is important sometimes

The emoji movie had a 8% score at rotten tomatoes. Photo credits to Michael Steber

I wonder if there was any quality department inside Sony pictures that didn’t realized about how bad does the idea of this movie actually is. This is the equivalent to the story about how small testing can save tons of money to a company. Probably the correlation is so arbitrary, but it is a good example of why everything should have a quality measurement (it doesn’t matter if it is a movie, a book or a software system)

No bugs in here! 🦗

One of the main goals in this blog is to prevent the usage of the word bug to refer to a fault, error or failure in a program. Maybe it is a word rich in history but in this blog I will try to follow the advices of Paul Ammann and Jeff Offutt writers of the Introduction to Software Testing book to don’t encapsulate all the different meanings into only one word.

But that’s another history for a different post. See you later