Chapter 4

At first, this is our Calc class:

public class Calc {    
static public int add (int a, int b) {
return a + b;
}
}

It only has the add method. Hence, we made failing tests for two methods to be implemented: mult and div, for multiplication and division. 

And a failing test for the add method as well.

The input values for the addition are incorrect. Also, the mult and div message are not recognized by the class.

As we can observe, all tests failed…

testAdd failed
testDiv failed
testMult failed

Then, we changed the testAdd input values, so the test won’t fail.

Now the addition will be correct.

Next, we implemented the methods for multiplication and division in the Calc class:

Calc now has three methods

Finally, we ran the tests again and had a successfull execution.

The class recognizes all Calc methods.
Advertisements

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

Week 4 Delivery

In this week we didn’t do anything related to the project, otherwise we focused more on the part of getting more involved in testing and we did choose the technologies for testing in JavaScript: Mocha and Chai.

“Mocha is a feature-rich JavaScript test framework running on Node.js and in the browser, making asynchronous testing simple and fun.”

https://mochajs.org/

“Chai is a BDD / TDD assertion library for nodeand the browser that can be delightfully paired with any javascript testing framework.”

https://www.chaijs.com/
Resultado de imagen para chaijs

On the other hand, we did meet up and did the team homework, research about testing and its techniques and best practices.

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.

Week 4 Plan

For this week we will finish some of the tasks we were supposed to finish last time as:

  • Create Software Requirements Specification Document
  • Define Unit Tests

Last time we researched about some technologies for testing. So this week we will choose one and start working on them.

Other thing we will do is personal tasks:

  1. Kevin: Work on software requirement specification
  2. Julia: Define unit tests
  3. Samuel: Set up the tests environment for the specifications.

Every task is managed in Github project tool: https://github.com/samosunaz/wa-integration/projects/1

Week 3 Review

Send email to Abraham

We made sure that both, Abraham and Gera, the product owner, agreed to have the project for the Quality and Testing class.

Research other technologies that will interact with WhatsApp API for SugarCRM.

You can find the document for this research here

Find options for unit testing in Javascript

We found good options such as Jasmine, Mocha, JsUnit, Jest, Karma,… We’re still deciding what’s the best framework for the project.

References

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/

Week 3 Plan

Tasks for this week:

  • Send email to Abraham
  • Research other technologies that will interact with WhatsApp API for SugarCRM.
  • Research iFrame + WhatsApp
  • Find options for unit testing in Javascript.
  • Create Software Requirements Specification Document
  • Define Unit Tests
There will be an issue on Github for each task.
We will administrate the issues and other stuff as spikes in the project. Link in here

And also a little of organization in here

And we store most of the documentation in here

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 .


Semester Plan

  • Week 1
    • Planning
  • Week 2
    • Planning
  • Week 3
    • Planning
  • Week 4
    • Research SugarCRM API documentation
    • Research for the best way to integrate WhatsApp into a webpage
  • Week 5 – Week 10
    • Development
  • Week 11 – Week 13
    • Quality and Testing
  • Week 14
    • Deployment

This plan is an estimation, it can change through the time