Autor: Richie Palma

DevOps

A series of DevOps labs were scheduled for the course. This post will cover what was done for this assignments.

Part One

Part Two

A setup for the next parts was required. The specifications are the next ones:

  • Lubuntu 18.10 right on hardware.
  • Java.
  • Git.
  • Node.js

Afterwards, a small test for the crontab command was made to learn the use of this. In my case I used it to set up a shutdown at 2:00 am in case I fall sleep with the laptop turned on and a timer of 30 minutes so I can cancel it in case I’m still awake.

crontab

Part Three

Part Four

Part Five

Chapters 6.1-6.2 (Team)

What two properties must be satisfied for an input domain to be properly partitioned?

It needs to have completeness and for each input not to overlap.

What is an Input Domain Model (IDM)?

Is the partitioning of domains into blocks and combining such blocks for each
parameter. Sometimes parameters are independent and sometimes they are in a conjunction.

What gives more tests, each choice coverage or pair-wise coverage?

Pair-wise coverage (PWC) because they is a minimum of n combinations while Each Choice Coverage (ECC) are permutations.

Unit Tests

For the Software Quality & Testing course we make use of an Unit Testing Homework. In the case of this blog, JUnit for Java is used to develop TDD.

It is simple to use JUnit if one uses Eclipse as it is already integrated into it. Following the tutorial set by Eclipse Tutorials one can either download the JAR compressed file (if not using Eclipse) or create a new JUnit test case within Eclipse by right-clicking the .java proyect in the “Package Explorer” window > New >JUnit Test Case

create new JUnit

Previously we made a Calc.java program that makes 4 simple operations: sums, subtractions , divisions , and multiplications.

calc

And a simple JUnit test for this called CalcTest.java

Calctest

Running such test will open a separate window in Eclipse called “JUnit”. In this window, the results of the testing will be deployed. Telling the programmer which tests passed and which ones failed.

calctesting

Secret Life of Bugs

Bugs have been part of software engineering as long as history goes. That is why there has been the curiosity of studying the patterns of these. Jorge Aranda and Gina Venolia both aim this objective in their research paper “The Secret Life of Bugs: Going Past the Errors and Omissions in Software Repositories”

It is impressive the amount of bugs and their reasons that prompted in this study. Yet makes one wonder the costs of this bugs when one is aware of them. Weather it better to fix them or not. This is because one of the patters is to ignore the bug and implement the solution later or not at all. Is this based on the importance and impact such bug has in the software.

The study done by Jorge Aranda and Gina Venolia was a great example of how code review becomes an important factor in software development at all times. This is because a bug can bypass automated analysis and tests because social, organizational and technical knowledge were needed.

Chapter 4 (Group)

Instructions

  • Answer Exercise#1 (see below) from Chapter 4 as a group on your blog with code links to GitHub. Remember to link to the files (not the main GitHub repo).

Question text from the book (slightly edited for our course).

Chapter 3 contained the program Calc.java. It is available on program listings page on the book website.

Calc currently implements one function: it adds two integers. test-driven design to add additional functionality to subtract integers, multiply two integers, and divide two integers. First create a failing test for one of the new functionalities, modify the class until the test passes, then perform any refactoring needed. Repeat until all of the required functionality has been added to your new version of Calc, and all tests pass.

Remember that in TDD, the tests determine the requirements. This means you must encode decisions such as whether the division method returns an integer or a floating point number in automated tests before modifying the software.

Submit all code including your final version of Calc, a screenshot showing that all tests pass. Most importantly, include narrative describing each TDD test created, the changes needed to make it pass, and any refactoring that was necessary.

Answer

First we create the test for this software. We decided to leave the operations as integers since the inputs are such type.  For the test it is known that a division by 0 is not possible so we catch an Arithmetic Exception in case this happens. However, Java automatically throws this when it happens, so as long as the tests catches it, the code will pass the test.

The book asks us to create a failing test, so the first version of Calc.java will be called Calc1.java. In here we create an underflow by dividing a small number (1) by a big number (100000) so that the real answer is an even smaller number (0.0001) but the computer can’t hold the bits to that so it will give 0 instead, which is the incorrect answer.

Test Failed

In our case we decided to threat this underflow by throwing an Arithmetic Exception since the test can catch such issue. This Calc.java will pass the test CalcTest.java.

Test Passed

TDD experience before the course

Before starting, it is important to mention the use of the following sources:

https://embed.simplecast.com/97f546d8

There is a key word obtained from the podcasts called programmer happiness. Such keyword mentions the confidence from a programmer in the fact that one’s code will work. Despite such satisfaction David Heinemeier mentions that even if the code works, the process around it would differ a programmer’s satisfaction from others. Since each one of them prefer to work with TDD and others don’t.

Currently, based in Beizer’s Test Process Maturity Levels, I find myself barely reaching Level 1 where I test to show correctness. I can’t tell from an experts point of view of how TDD would work perfectly of how it won’t but breaking the code is an important part of software development; hence, a proper way of testing is necessary.

As from my experience at TDD. Competitive programming  within CodeForces and A2OJ sets an example of this. Providing a series of problems needed to be solved by code, one is provided with a series of tests that show up the input of the software and the output of the software. In this case, one works around this tests to see if their solution is right or not. However, they do not show up all of the tests, so one has to develop other tests from their own to reach the goal. This teaches programmers to not assume the code is right because it worked the first time, but to keep building tests and breaking the code to reach the most efficient and useful solution.