LEVELS OF SOFTWARE TESTING

Testing is very important to the development of a successful program. Without testing, there would not be any guarantee that a particular designed code would fulfill it design purpose. There are basically four level f testing namely Unit Testing, Integration Testing, System Testing and Acceptance Testing. I chose to explore and elaborate on these because we have just starting treating those topics in class starting with the Unit Testing. Due to time constraint, I would be describing the four levels of testing in a briefly manner as follows;

Unit Testing: Unit testing is done by programmers on a particular functions or code modules. White-box testing method is used to achieve this task.  Considering a code as a bulk program, unit testing will deal with each pieces of the code that comes together to form the code and make sure that each section of the code passes the test.  In this regards, it is easy to figure out which part of your code have a problem and solutions to non-functioning section of the code can be easily resolved. Sections of code can be testing on the go as they are created rather than wait till the end which might give you hard time figuring problem. Unit testing requires the knowledge of the internal program design and code.

Integration Testing: Integration testing is done after unit testing and it is a testing of combined parts of an application to determine their functional correctness. Unlike the unit testing which test individual pieces of the code, Integration testing gives you the opportunity to gather all the pieces or sections and test them as a group. This will enable you to determine how efficiently all the unit of your code is working together or to technically verify proper interfaces between modules and sub systems.

System Testing: System testing ensures that the system is in line with all the requirements and has meets the quality standards as well the code design purposes. It is the first level of testing the whole code or program to make sure the entire program is working as one unit. System test is often done by an individual who is not part of the developing group and it is very necessary because it ensures the program or code is meets the technical, functional and business requirements that they were tasked to design.

Acceptance Testing: Acceptance testing is related to the user and is designed for the user to test the system to see if it meets their standard. In other words, it is to verify that the system meets the user requirements. In this stage of testing, if nothing changes and the software passes, the program will be delivered to the entity they that need it and the programmers work is done.

It is important for one to note that all these levels of testing are done progressively from unit testing to acceptance testing. I have come to note that I cannot jump to acceptance testing without first doing the unit, integration and system testing. This is going to have a great impact in my career as I have now known and understand clearly how the testing is done.

References: https://www.seguetech.com/the-four-levels-of-software-testing/

From the blog CS@Worcester – Computer Science Exploration by ioplay and used with permission of the author. All other rights reserved by the author.

I began researching good JUnit practices as a follow-up to our discussions of it in class.  I found a post on the codecentric Blog by Tobias Goeschel entitled “Writing Better Tests With JUnit” that addresses the pros and cons of JUnit and provides tips on how to improve your own testing.  This is the most thorough article I’ve found on JUnit testing (and possibly longest), so it seems fitting to summarize it in a blog post of my own while we cover the subject in class.

From the blog CS@Worcester – by Ryan Marcelonis and used with permission of the author. All other rights reserved by the author.

Toward the end of our discussion about the Strategy design pattern, we briefly talked about the open/closed principle; I wanted to further my understanding of this concept, so I decided to do some research of my own.  Today, I will summarize an article by Swedish systems architect Joel Abrahamsson entitled “A simple example of the Open/Closed Principle”.

Abrahamsson begins the article by summarizing the open/closed principle as the object oriented design principle that software entities should be open for extension, but closed for modification.  This means that programmers should write code that doesn’t need to be modified when the program specifications change.  He then explains that, when programming in Java, this principle is most often adhered to when implementing polymorphism and inheritance.  We followed this principle in our first assignment of the class, when we refactored the original DuckSimulator program to utilize the Strategy design pattern.  We realized, in our in-class discussion of the DuckSimulator, that adding behaviors to Ducks would force us to update the implementation of the main class as well as each Duck subclass.  By refactoring the code to implement an interface in independent behavior classes – and then applying those behaviors to Ducks in the form of “setters” – we opened the program for extension and left it closed for modification.  Abrahamsson then gives his own example of how the open/closed principle can improve a program that calculates the area of shapes.  The idea is that, if the open/closed principle is not adhered to in the implementation of a program like this, it is susceptible to rapid growth as functionality is added to calculate the area of more and more shapes.

(Note: This is clearly not a Java implementation.)

public double Area(object[] shapes)
{
    double area = 0;
    foreach (var shape in shapes)
    {
        if (shape is Rectangle)
        {
            Rectangle rectangle = (Rectangle) shape;
            area += rectangle.Width*rectangle.Height;
        }
        else
        {
            Circle circle = (Circle)shape;
            area += circle.Radius * circle.Radius * Math.PI;
        }
    }

    return area;
}

( Abrahamsson’s implementation of an area calculator that does not adhere to the open/closed principle. )

public abstract class Shape
{
    public abstract double Area();
}

public class Rectangle : Shape
{
    public double Width { get; set; }
    public double Height { get; set; }
    public override double Area()
    {
        return Width*Height;
    }
}

public class Circle : Shape
{
    public double Radius { get; set; }
    public override double Area()
    {
        return Radius*Radius*Math.PI;
    }
}

public double Area(Shape[] shapes)
{
    double area = 0;
    foreach (var shape in shapes)
    {
        area += shape.Area();
    }

    return area;
}

( Abrahamsson’s implementation of an area calculator that adheres to the open/closed principle. )

Abrahamsson ends the article by sharing his thoughts on when the open/closed principle should be adhered to.  He believes that the primary focus of any good programmer should be to write code well enough that it doesn’t need to be repeatedly modified as the program grows.  Conversely, he says that the context of each situation should be considered because unnecessarily applying the open/closed principle can sometimes lead to an overly complex design.  I have always known that it is probably good practice to write code that is prepared for the requirements of the program to change, and this principle confirmed that idea.  From this point forward, I will take the open/closed principle into consideration when tackling new projects.

From the blog CS@Worcester – by Ryan Marcelonis and used with permission of the author. All other rights reserved by the author.

Software Design Patterns

Depending on the type of project you are designing, there will always be a need to adopt a particular pattern that clearly represents your design. There are many design patterns that a programmer can rely on to present his or her project. For the purpose of studies, I will be exploring and discussion the three most useful design patterns categories. Thus creational design pattern, structural design pattern and Behavioral design pattern. Below is a brief description of each pattern.

Creational Design pattern: This type of design create object as needed within a code and allows for abstract factory which group objects of similar functionality. This also uses polymorphism to allow one object to inherit multiple behaviors within a method. In this pattern, you do not need to declare the exact class or type because polymorphism is used at the end to assign behavior. Usually, an abstract prototype is created and the base classes that inherit it are defined.

Structural Design pattern: Structural patterns deals largely with composition of classes and object by using inheritance and interfaces to enable objects to gives out new functionality. It often has an abstract class which uses method signatures and behaviors for the classes that will implement the interfaces. In structural patterns, objects are group according to their behavior and what they inherit. Also, modifications of object are done before finalizing your code.

Behavioral Design pattern: This is a type of pattern that allows for the behavior of a class to change base on it current state; even though, these states are always changed in the entire programming, implementation of each state is defined by a unique interface. It also allows for new operations to be added to an object without having to modify its original implementation structure.

In general, when you are talking about code responsibility, you really want to have your methods to your classes do one thing and do it well. Bringing it to real life example, it is like texting and driving; there is no way to achieve both effectively at the same time. You are either going to be driving off the road while texting well or driving well and not texting regularly. This implies, having your code do two or more things will make it do one thing well and do badly with the rest. Also, changing one thing on base class might have side effect on the other too. In this case, as a designer, you will want to extend your classes rather than modifying them. Even though you will have more classes created in order to have them do one thing, it is worth doing that because it will provide a clear presentation of your code. This is going to help me a lot in the future because I am going to adopt having classes of my code perform one task which will provides higher efficiency.

References:

https://airbrake.io/blog/design-patterns/software-design-patterns-guide

From the blog CS@Worcester – Computer Science Exploration by ioplay and used with permission of the author. All other rights reserved by the author.

This week I read an article about the Benefits of using assertThat over other Assert Methods in Unit Tests. Since in our reading materials prof. Wurst is using assertThat instead of traditional Asserts, I think it is time to familiarize myself with the new asserting statements.

According to the article, AssertThat method incorporates the use of the hamcrest library and is a much improved way to write assertions. It uses what’s called matchers which are self-contained classes which have static methods that get used with the assertThat method. These static methods can be chained which gives a lot of flexibility over using the old assert methods.

Until now I have been using assertequals while writing my test cases. The biggest issue I had was to remember the correct ordering of (expected, actual) in assertEquals(expected, actual) statement. The keywords ‘expected’ and ‘actual’ used were not even informative enough to determine what exactly goes in it. With the use of assertThat method I don’t see such complications. The first benefit I see is that assertThat is more readable than the other assert methods. Writing same assertion with assertThat looks like:

assertThat(actual, is(equalTo(expected)))

It reads more like a sentence. Assert that the actual value is equal to the expected value, which make more sense.

Similarly, to check for not equals, used to be:

assertFalse(expected.equals(actual))

Now with the use of assertThat it will be:

assertThat(actual, is(not(equalTo(expected)))

The “not” method can surround any other method, which makes it a negate for any matcher. Also, the matcher methods can be chained to create any number of possible assertions. There’s an equivalent short-hand version of the above equality methods which saves on typing:

assertThat(actual, is(expected))

assertThat(actual, is(not(expected)))

Another benefit to assertThat is generic and type-safe. The below given example of assertEquals compiles, but fails:

assertEquals(“abc”, 123)

The assertThat method does not allow this as it typed, so the following would not compile:

assertThat(123, is(“abc”))

This is very handy as it does not allow comparing of different types. I find this a welcome change.

Another benefit to using assertThat are much better error messages.  Below is a common example of the use of assertTrue and its failure message.

assertTrue(expected.contains(actual))

java.lang.AssertionError at …

The problem here is that the assertion error doesn’t report the values for expected and actual.  Granted the expected value is easy to find, but a debugging session will probably be needed to figure out the actual value.

The same test using assertThat:

assertThat(actual, containsString(expected))

java.lang.AssertionError: Expected: a string containing “abc”

In this case, both values are returned in the error message. I think this a much better since in many cases a developer can look at the error message and figure out right away what they did wrong rather than having to debug to find the answer. That saves time and hassle. I am excited to get my hands on with the new AssertThat method in my upcoming days.

Source: (https://objectpartners.com/2013/09/18/the-benefits-of-using-assertthat-over-other-assert-methods-in-unit-tests/)

From the blog CS@Worcester – Not just another CS blog by osworup007 and used with permission of the author. All other rights reserved by the author.

Today I will be talking about an article called “Builder Design Pattern” put out by JournalDev.com. According to the article, the builder design pattern is used to fix some issues that arise when the factory and simple factory design patterns are implemented. The article points out three major problems that come up when using the factory patterns. The first problem is that there can be too many arguments to pass to the factory, which causes error due to the factory not being able to keep track of order. The next problem is that all the parameters must be passed to the factory. If you don’t need to use the parameter, you still need to pass null to it. The last problem occurs when object creation is complex. The factory will become complex, and it will difficult to handle. So what’s the solution to all of this? The builder pattern.

So what is the builder pattern? The builder pattern builds objects by individual step, and uses a separate method to return the object when it has been created. This is a great way to implement a “factory” pattern when the object you are trying to create has a large number of parameters. The article uses an example of the builder pattern by writing a java program that builds computers. Two classes, Computer and ComputerBuilder are used. The Computer class has a private Computer constructor, which has the required parameters as arguments. The Computer constructor sets all of the parameters, including the optional ones. Then the ComputerBuilder class is called; note this is a nested class. This class, in addition to being nested, is also static because it belongs to the Computer Class. The ComputerBuilder Class has a ComputerBuilder method which is public, and this method sets the parameters as this.parameter. The ComputerBuilder Class has two other methods used to set the optional parameters as this.parameter. The final method is a builder method, which in this case is public Computer build(), and this method will call the this.parameter arguments to build a computer object. Then it will return the object.

I chose this topic because I have experienced the problems mentioned above when using the factory pattern. If there are a lot of parameters to be passed, it can become extremely tedious to code. It also becomes very difficult to keep track of what’s happening as the code becomes more cumbersome to handle. I will definitely have to try implementing the builder pattern because it seems to function like the factory pattern, but in a simpler, easier to understand way. I really like the idea of only having to worry about required parameters and being able to set optional parameters outside of the constructor class. This eliminates having to pass null to the constructor, which should help with the compile time errors. This article uses java example, and it helped me really understand the code as well as the idea behind the code.

Here’s the link: https://www.journaldev.com/1425/builder-design-pattern-in-java

From the blog CS@Worcester – The Average CS Student by Nathan Posterro and used with permission of the author. All other rights reserved by the author.