9/25/2017 — Blog Assignment 2 — CS 343

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.

9/25/2017 — Blog Assignment 2 – CS 443

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.

3. User Name
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.

9/18/2017 — 1st Blog Post CS 343

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.

9/18/2017 — 1st Blog Post Assignment CS 443

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 =.
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.