http://blog.synopse.info/post/2015/05/03/SOLID-Design-Principles
The topic for this week is on SOLID. SOLID stands for:
Single responsibility principle: when objects only have only 1 responsibility.
Open/closed principle: when software is opened for extension, but closed for modification.
Liskov substitution principle: when objects in a program are replaceable with instances of subtypes without significantly altering the program behavior
Interface segregation principle: when many client specific interfaces are better than one general purpose interface.
Dependency inversion principle: when one should depend on abstractions.

SOLID provides the best-practice guidelines and can help fight against 3 main code weaknesses:
Rigidity: Changes are hard since system parts are dependent upon many other parts.
Fragility: Making changes may break parts of the system.
Immobility: part of system cannot be reused in another application because it cannot be disentangled from the current application.

What I thought was interesting was the open/closed principle. Accordingly, when a class or unit is defined at the same time, it is either open for extension or closed for modification. This behavior allows existing code to be extended without breaking its initial behavior. Conformance to this policy allows for code reusability, code maintainability, and code extendibility without breaking the initial behavior of the program. An example that does not abide by this rule is a rectangle class for calculating the area of a rectangle. Say we want to extend it to calculate the area of a triangle. Then, extend it to calculate for the area of a circle. The class requires 3 different modifications. This implies that the area calculator class is not closed for modification as it needs to be changed in order to be extended, so it is not opened for extension. In large scale software development, these modifications are impractical. Instead, what would abide by this rule is a general area and shape class. This will allows for extension for the program, but its initial behaviors are closed for modifications.
The last topic that I thought was interesting was the Liskov substitution principle. The Liskov substitution principle states that if an object of type for example TChild is a subtype of another object of type TParent, then the TChild can substitute for the TParent without making major modifications to the desired properties of a program. The example presented was that of stacks and queues. If both have push and pop methods, since the storage behavior of stacks and queues are the opposite of one another they cannot inherit from a single parent type. Switching the behaviors of the stack with a queue for example will result in unexpected behavior during execution.
To adhere to this principle, the following should apply:
Class or interface definition should be properly named or commented. “behavior ” design patterns should be used when defining object hierarchy. Tests should use abstract local variables. Finally, class hierarchy should be separated.
I chose this article because it introduces one of the best practice guidelines in software engineering. For example, conformance to the open/closed policy allows for code reusability, code maintainability, and code extendibility. So, I chose it for learning purposes in order to improve coding practices for my own programs. Programming concepts for me is based on scope and visibility. Some of these programming guidelines helps create organizations in the code.

From the blog CS@Worcester – Site Title by myxuanonline and used with permission of the author. All other rights reserved by the author.

http://testerstories.com/2014/06/path-testing-the-coverage/
This week we turn to path coverage. Path coverage refers to test cases with linearly independent paths, in which a given program will execute at least once. A linearly independent path maps out the control flow of an application, which visually describes the execution path of a program in a sequence. Control flow graphs are numbered in sequence through all parts of a program. Each numbered segments serves as nodes in the execution path.
The article introduces the following coverages and their paths:
Node coverage has test cases that goes to every node in the graph.
Link coverage has test cases that goes to every link or line in the graph.
Loop coverage has tests that explores the interactions between sub-paths within a loop.

Node Coverage
1 2
1 3 4 7 6 8
1 3 4 5 6 8

Link Coverage
1 3 4 3 4 5 3 4 5 6 8

Loop Coverage
1 3 |4 3| 5 7 8
1 3 |4 3| 7 6 8
1 3 4 |5 3| 4 5 6 8
…
Through the different coverages, the example above shows the different paths that can be taken in the example program. What this example shows is that path testing maps out the control flow of an application and its execution paths to test out its coverages.

The coverage that I thought was interesting was statement coverage. Statement coverage is the lowest level testing coverage. It tests whether the flow of control has reached every executable statement at least once. The goal is to map out each executable code at least once.
The following example was given:
public class compute {
public static void main(String[] args) {
(1) float x = Float.valueOf(args[0]);
float y = Float.valueOf(args[1]);
(2) if (x != 0)
(3) y += 10;
(4) y = y / x;
(5) System.out.println(x + ” ” + y);
}
}
This maps out the path
3
1 -> 2 —>4 -> 5
Statement 2 divides into 2 conditionals, whether x is equal to 0, corresponding to condition 4, or not, corresponding to condition 3.
Statement coverage is defined by a percentage of number of statements executed over the total number of statements in the source code*100.
In this case the total number of statements in the source code is 5. If x = 0, then the number of statements executed is 4, providing 80% coverage. If x != 0, then this provides 100% coverage.
I first chose this article to learn more about path testing and coverage. I did not thoroughly understand the concept introduced in class until I went through this article. Though short, it provides a brief overview of the different coverages. However, the examples given in the article for the different types of coverages are inadequate. I particularly liked the examples provided for statement coverage. What I had learned is that statement coverage is simply a measure of how many execution paths are needed for 100% coverage. This demonstrates what path testing is all about, which is modeling the execution flow and testing its different paths for coverages.

From the blog CS@Worcester – Site Title by myxuanonline and used with permission of the author. All other rights reserved by the author.

https://sandit27.wordpress.com/2008/03/24/what-are-anti-patterns/
This week’s post focuses on Anti-patterns. Patterns defines a common solution to a problem that occurs through different settings. It is a general solution that can be specialized for a given context. In software design, it helps to capture the best practices that can be reused and applied in the development of different types of software.
In CS, anti-patterns are repetitive practices that appears beneficial, but will most likely result in bad consequences that will outweigh the advantages. It is called anti-pattern because the use will produce negative implementations. Two key elements are used to distinguish an anti-pattern:
A repetitive pattern that appears beneficial but ultimately produces negative results that outweighs its advantages.
A refactored solution that has been documented, proven in practice, and repeatable.
Anti-patterns should be diagnosed early. The following are some of the classic Anti-Patterns:
Organizational anti-patterns:
The “I told you so” the ignored warning from an expert is justified.
Mushroom management is when employees are kept uninformed or misinformed.
Project management anti-patterns:
The smoke and mirrors shows how unimplemented functions will appear.
Finally, software bloat is for allowing successive versions of a system to demand more resources.
I chose this topic because I thought a blog post on anti-pattern of function as child component was interesting. The post can be found following this link, http://americanexpress.io/faccs-are-an-antipattern/. The article argued that Function as child component, FACC is an anti-pattern. FACC is a pattern that allows users to pass a render function to a component as child prop. It allows users to pass as children to a component/function.
FACC was argued to be an anti-pattern. The example was a summation function of 2 numbers and returns the result. Clean code practices recommends descriptive names for properties, variables, and functions. So, in this case the best practice is to name it as add or sum, but not children. The function passes render callback functions through a prop named children. The main issue here is that the FACC function uses the prop children to pass in render callbacks. This pattern goes against what is considered best practice, so it is an anti-pattern.
I chose this article because it introduces an anti-pattern in a reactjs function and reactjs articles are always an interesting read. It argues that naming props as children in the FACC function was not the best practice. It goes against what is considered to be the “Clean Code” standards. I thought that this article was worth a blog post because it was an interesting read.

From the blog CS@Worcester – Site Title by myxuanonline and used with permission of the author. All other rights reserved by the author.

Equivalence Class Testing
This week we turn to equivalence class testing. Equivalence class testing is a black box software testing technique that divides function variable ranges into classes/subsets that are disjoint. It is beneficial for two cases:
When exhaustive testing is required.
When there is a strong need to avoid redundancy.
Equivalence class testing selects test cases one element from each equivalence class. This helps to reduce redundancy.
There are 4 types of equivalence class testing:
Weak normal equivalence class testing: The term weak refers to single fault assumption. This is accomplished by using one variable from each equivalence class in the test case.
Strong normal equivalence class testing: The term strong refers to multiple fault assumption. This method uses test cases from each element of the cartesian product of the equivalence classes. The cartesian product guarantees the notion of completeness in that all of the equivalent classes are covered and there is one of each possible combination of inputs.
Weak robust equivalence class testing: This term combines weak with robust, meaning single fault assumption with invalid values.
Strong robust equivalence class testing: This term combines strong with robust, meaning multiple fault assumption with invalid values. The test cases are the cartesian product of all the equivalence classes.
This article talks about redundancy in equivalence class testing. It introduces the following problem: Suppose a there is a UI for creating user accounts. The Username is between 1 and 25 characters, spaces are not allowed. The gender can be Male or Female. It would be impossible to test all combinations of inputs instead we turn to equivalence class testing.

Breaking the conditions down EC reduces the test cases into 5 equivalence classes.

Field
Description
3. User Name
Empty
4. User Name
Length > 25 (no spaces)
5. User Name
Length > 25 (containing a space)
6. User Name
Length >1 and = with >.

I chose this post for its simplicity and example of the UI for creating user accounts. The example helps to connect the concept of EC to test cases that can be validated. So, it helps to break down the problem into different ECs and its product into different test cases. It also demonstrates the advantages of EC in helping to reduce redundancy and test time. I chose this post because it gives a good example of EC testing.

From the blog CS@Worcester – Site Title by myxuanonline and used with permission of the author. All other rights reserved by the author.

http://creately.com/blog/diagrams/class-diagram-relationships/
I thought class diagrams were complex when first introduced, but this blog post breaks it down into simple concepts that are easier to understand. This article has helped me a lot in learning the current course materials on class diagrams. It has helped me to determining and distinguishing the different components in class diagrams and their relationships, which are applicable in object-oriented modeling.
As stated in the article class diagrams are the main building blocks in object-oriented modeling. Their main function is to show the relationship between different objects in the system. This includes their attributes, operations, and relationships among them. Classes in a class diagram are represented as boxes partitioned in three. An example of a class is the loan account with three partitions. The first is the class name, which in this case is loan account. The middle is the class attributes which are the type, accountName, dateReleased, and loanAmount. The last is the method or possible operations associated with the class. The example shows all of the relevant data of a particular object in a systematic and clear way. A class diagram is simply a collection of classes.
Relationships between classes are interrelated through different types of logical connections. The following are the different types:
Association – encompasses just about any logical connection or relationships between classes.
Directed Association – shows directionality with an arrowhead, arrowhead depicts a container-contained directional flow
Reflexive Association – occurs when classes may have multiple functions or responsibilities.
Multiplicity – active logical connection when cardinality of class in relation to another is depicted.
Aggregation – formation of particular class as result of one class being aggregated or built as a connection, directionality is a diamond shape near the parent class to the child class.
Composition – similar to aggregation, difference being emphasizing dependence of contained class to life cycle of container class, directionality line is a diamond shape adjacent to the container class and directionality arrow to the contained class.
Inheritance/Generalization one associated class is a child of another by virtue of assuming same functionality, to show relation a solid single arrowhead is drawn from the child class to the parent class, with the arrowhead unfilled
Realization – shows implementation of functionality defined in one class by another class, relationship is indicated by broken lines.
This article was a overview of class diagrams. I chose it for its simplicity in explaining design concepts. It is worth reading for someone looking for a review and it has helped me a lot in understanding the course materials.

From the blog CS@Worcester – Site Title by myxuanonline and used with permission of the author. All other rights reserved by the author.

http://urosv.blogspot.com/2008/03/boundary-value-analysis-bva.html
Staying current with the current course topic and keeping things as simple as possible, this blog post gives some interesting examples of boundary value testing that I believe are helpful for understanding the course material on boundary value testing.
Boundary value testing is a simple concept of error checking range functions at the boundary. As stated in the article, it is one of the most important techniques for test case designs that every software developer will come across. It is basically a black box testing technique where knowledge of the source code is not required.
Boundary value testing checks for off-by-one error, a common mistake in computer programming. The most common off-by-one error are the following:
misplacing < with with >=.
Under indexing or exceeding the limit of the storage space of an array
incrementing and decrementing variables that are not needed or failing to do so when needed.
loop conditionals
The simplest example given is that of N apples assembled in a straight line. Each apple is a assigned a number corresponding to its position. Taking all apple from p to q, including the two variables, q-p apples will be off by one, whereas q-p+1 will include all of the apples needed in counting.
Another example given is a function which colors rectangles with coordinates of the upper left and bottom right points. The code given are as follows:

if (points > 90) grade = ‘A’;
if (points > 80 && points 70 && points 60 && points 50 && points < 60) grade = 'E';
if (points < 50) grade = 'F';

This a a typical off-by-one error. The error that needs correction is the < sign which has to be <=. The error is that the last column and row of the rectangle is not colored in.
The final example are simply boundary ranges, say from 1-10. Some good test cases are 1 and 10 or 0 and 11, or perhaps 2 and 9. This is a typical example that is much like the exercises done in class or on the hw assignments.
This blog post gives a variety of interesting examples of a simple concept in boundary value testing that is off-by one error that was not shown in the examples in class or on the hw assignment that I think are worth noting for any entry level programmer. It gives a brief overview of different test cases that any programmer should try to avoid. It gives a decent overview of boundary value testing which is a simple concept of testing boundary values of functions that takes in ranges of independent variables. Those are the reasons why I choose this post for last week’s blog post assignments.

From the blog CS@Worcester – Site Title by myxuanonline and used with permission of the author. All other rights reserved by the author.