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.

http://sahandsaba.com/nine-anti-patterns-every-programmer-should-be-aware-of-with-examples.html

This blog post covers 9 anti-patterns that are common in software development.

1. Premature Optimization – Optimizing before you have enough information to make conclusions about where and how to do the optimization. This is bad because it is hard to know exactly what the bottleneck will be before you have empirical data.
2. Bikeshedding – Spending excessive amounts of time on subjective issues that are not important in the grand scheme of things. This anti-pattern can be avoided by prioritizing reaching a decision when you notice it happening.
3. Analysis Paralysis – Over-analyzing so much that it prevents action and progress. A sign that this is happening is spending long periods of time on deciding things like a project’s requirements, a new UI, or a database design.
4. God Class – Classes that control many other classes and have many dependencies and responsibilities. These can be hard to unit-test, debug, and document.
5. Fear of Adding Classes – Fear of adding new classes or breaking large classes into smaller ones because of the belief that more classes make a design more complicated. In many situations, adding classes can actually reduce complexity significantly.
6. Inner-platform Effect – Tendency for complex software systems to re-implement features of the platform they run in or the programming language they are implemented in, usually poorly. Doing this is often not necessary and tends to introduce bottlenecks and bugs.
7. Magic Numbers and Strings – Using unnamed numbers or string literals instead of named constants in code. This makes understanding the code harder, and if it becomes necessary to change the constant, refactoring tools can introduce subtle bugs.
8. Management by Numbers – Strict reliance on numbers for decision making. Measurements and numbers should be used to inform decisions, not determine them.
9. Useless (Poltergeist) Classes – Classes with no real responsibility of their own, often used to just invoke methods in another class or add an unneeded layer of abstraction. These can add complexity and extra code to maintain and test, and can make the code less readable.

I chose this blog because anti-patterns are one of the topics on the concept map for this class and I think they are an interesting and useful concept to learn about. I thought this blog was a very good introduction to some of the more common anti-patterns. Each one was explained well and had plenty of examples. The quotes that are used throughout the blog were a good way of reinforcing the ideas behind each anti-pattern. I will definitely be keeping in mind the information that I learned from this blog whenever I code from now on. I think this will help me write better code that is as understandable and bug-free as possible.

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

The blog post I chose this week comes from stickyminds.com and discusses how the quality assurance testing process is changing.  In the post (https://www.stickyminds.com/article/4-strategies-structured-qa-process) Praveena Ramakrishnan gives a general overview of the old way of testing where the tester was just focused on finding bugs.  Then they discuss how their next job gave her a different perspective.  That her job wasn’t just to find the bugs and try to break the program, but to work as a team towards the overall improvement of the software.  I think she has a positive view of her role as a tester and how employ some strategies to continue that positive mentality.  Her first strategy is to review documentation.  This is a good reminder for testers at all levels.  When approaching a project we need to remember not to rush into writing tests before we read the documentation and have a solid understanding of not only what the program is doing, but also try and gain some perspective of what the designers want the program to do.  The second strategy is to research past defects.  When we look at the past issues we can try to identify if there are any patterns.  This could help speed up future testing by improving the efficiency.  She then emphasizes that it is important to triage the defects.  When we as testers find a bug we should report it as soon as possible, but that is only the beginning.  After that we should look into what caused the issue to occur and what version it was added to the code.  This again helps paint a fuller picture of the defects and the code in general so that we can identify any patterns and try to improve in the future.  This goes into the last strategy which is to go beyond the reported issue.  Try and look beyond just your tests.  If you have logs review them as well.  The tests may pass, but you notice other errors occurring.  Catching these can improve future performance as well as prevent future defects.  Going above and beyond the minimum also typically results in higher pride in your work.  Employing these strategies will have a snowball effect to your job.  While you may not see a clear difference overnight keep working on implementing them and over time your skills will improve leaps and bounds over your peers.  Remember that it’s not just about breaking the application until the developers fix all the bugs, it’s about being a part of a team that strives to create the best product possible.

From the blog CS@Worcester – Tim's Blog by nbhc24 and used with permission of the author. All other rights reserved by the author.

Link to Blog: http://it.toolbox.com/blogs/enterprise-solutions/object-oriented-testing-issues-21274

This blog explains the issues of object oriented testing. Craig Borysowich identifies the strategies of object oriented testing, the strategies for selecting test cases, and the levels of testing, which are all involved in analyzing the testing process. In the beginning of his blog, Borysowich states that testing in an object oriented context must address the basics of testing a base class and the code that uses the base class. Factors that affect this testing are inheritance and dynamic binding. Dynamic binding is also known as dynamic dispatch. Since the factors that affect this testing are inheritance and dynamic binding, it brings up the point that some systems are harder to test than others. For example, systems with inheritance of implementation are harder to test than inheritance of interfaces.

Some object oriented testing strategies include white-box and black-box testing. Two assessments that determine the strategies to select test cases include the assessments of “likely faults” and “likely usage.”

“Likely Faults” involve types of tests which are based on practical experiences of areas in which errors are most likely to occur. For example they can occur from certain syntax in a particular programming language or boundaries such as beginning and end conditions. “Likely Usage” involve types of tests that test to exercise the system in the ways that the user of the system will be likely to use the system, or aim to test completely the elements of the system most likely to be used. These strategies apply to structural and behavioral testing.

The levels of testing that object oriented testing undergoes are Unit, Integration, and Acceptance levels. The Unit test is more effective in the overall system than with procedural unit tests. Integration test focuses on interactions among classes. It is recommended that units be integrated in an incremental fashion at a steady rate. Acceptance test ensure that all of the use cases appear in a test.

I chose this blog because I wanted to know what the necessary processes are when it comes to object oriented testing and its pros and cons. Borysowich briefly explains what these processes and steps are when it comes to object oriented testing and how it can involve Unit, Integration, and Acceptance levels of testing. Knowing the two assessments of “likely faults” and “likely usage” helps determine what strategies to use when choosing test cases. Object Oriented testing will be useful to know, especially when it comes to video games. There are games that have implemented object oriented programming, and it is important to understand the issues and solutions when it comes to testing in thwe object oriented environment.

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

Link to blog: http://www.programmr.com/blogs/5-solid-principles-object-oriented-software-design

This blog gives the description of the 5 different types of design principles. These principles include the Single Responsibility Principle, Open-Closed Principle, Liskov Substitution Principle, Interface Segregation Principle, and the Dependency Inversion Principle. The acronym “SOLID” represents these principles in the given order:

S – Single Responsibility Principle

O – Open-Closed Principle

L – Liskov Substitution Principle

I – Interface Segregation Principle

D – Dependency Inversion Principle

Single Responsibility Principle:

“A class should only have one reason to change” is how the author of this blog describes this principle. This principle states that every class in your software should have one and only one responsibility.

Open-Closed Principle:

“Software entities should be open for extensions, but closed for modification.” This means that software systems should be available for change. Customers will request new features and changes to existing features. Designing a system such that changes or extensions in requirements can be done by adding subclasses instead of changing existing code is a way to avoid rewriting an entire system.

Liskov Substitution Principle:

“Derived classes must be substitutable for their base classes.” This means that there will be some implementation of inheritance from understanding inheritance hierarchies and traps that can cause the open/close principle to fail with certain hierarchies. This principle fixes the violation that a function causes towards the open/closed principle.

Interface Segregation Principle:

“Make fine grained interfaces that are client specific.” This means that client code should not be aware of such a non-cohesive class as one unit. The class should have multiple interfaces and the client code should only be aware of the interface which is specific to its needs.

Dependency Inversion Principle:

“Depend on abstractions, not on concretions.” This means that this principle attempts to prevent a tangle of dependencies between modules by stipulating that entities and high level modules must not depend on concrete implementations but should depend only on abstractions.

The author of this blog identified the five design principles in a way that is easier to understand. He highlights the main concepts by providing a brief one sentence description about each principle. The acronym S.O.L.I.D. also makes it easier to understand on which design principles are which. I chose this blog because I wanted to know more about certain design principles. I previously knew the Single Responsibility and the Open-Closed principle, but didn’t know the remaining three. Understanding these principles will help me in my future career because there will be many different principles I will need to apply as a video game developer considering that there will be many different design principles involved for coding games.

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

This week I read an article on Observer design pattern. Since for my ‘Assignment 2 – Additional Design Patterns’ I was doing lots of research on Observer pattern (which I will be writing a tutorial on), I found this particular post to the most informative one.

Basically, the Observer pattern falls under behavioural pattern, as it’s used to form relationships between objects at runtime. The Observer pattern is the gold standard in decoupling – the separation of objects that depend on each other. The definition provided in the original Gang of Four book on Design Patterns states:

Define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically.

The idea behind the pattern is – one of more Observers are interested in the state of a Subject and register their interest with the Subject by attaching themselves. When something changes in Subject that the Observer may be interested in, a notify message is sent, which calls the update method in each Observer. When the Observer is no longer interested in the Subject’s state, they can simply detach themselves.

Fig. The UML diagram definition

James Sugrue, the author of the article, points the main benefit of using this pattern. He mentions that- to pass data onto the observers, subject doesn’t need to know who needs to know. Instead, everything is done through a common interface, and the notify method just calls all the objects out there that have registered their interest. This is a very powerful decoupling – meaning that any object can simply implement the Observer interface and get updates from the Subject.

Sugrue suggests using this pattern to reduce coupling. He argues – if you have an object that needs to share its state with others, without knowing who those objects are, the Observer is exactly what you need.

After reading about the SOLID principles for my first blog, I believe the observer pattern allows for the Open Closed principle, which stated that a class should be open for extensions without the need to change the class. Open Closed principle holds true while using the observer pattern as a subject can register an unlimited number of observers and if a new observer wants to register with the subject, no code change in the subject is necessary. Now, I feel I have a good understanding of the Observer pattern which helps me in writing a tutorial on it.

Source: https://dzone.com/articles/design-patterns-uncovered

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.

We’ve been going over the concept of design patterns during the past few weeks, so I thought it would be appropriate to do some research on those most commonly used. Subham Aggarwal has an informative blog on the topic entitled Top 3 Design Patterns in Java. We’ve been examining design patterns written in Java, so I feel that Subham’s blog is a great one to discuss. He provides excellent examples written in the Java programming language.

Subham first explains that design patterns are generally creational, structural or behavioral. He then introduces three design patterns that he speculates are the “top three” used in Java.

1. Singleton Pattern
2. Factory Pattern
3. Decorator Pattern

I covered the Singleton pattern in a recent blog so I will try not to duplicate anything posted in that entry. One aspect that stands out in Subham’s explanation that I ought to mention is his assertion that Singleton is one of the most “inappropriately used” design patterns in Java. Based on what we’ve learned so far, it seems to me that the true intent of Singleton is to have just one instance of each Singleton class. But Subham states that many developers seem to manipulate the pattern in an attempt to have Singleton classes act as global variables, which is not what this pattern is intended to do. Based on Subham’s breakdown and what we’ve learned in class, I would have to say that I believe the Singleton design pattern seems to be a creational one.

Next discussed is the factory pattern, which Subham describes as a way to create certain objects based on the user’s specification. For instance, he provides the following code as an example:

public class ShapeFactory {
 
 // use getShape method to get object of type shape 
 public Shape getShape(String shapeType) {
     if (shapeType == null) {
     return null;
     } 
     if (shapeType.equalsIgnoreCase("Quadrilateral")) {
          return new Quadrilateral();
     }
     else if (shapeType.equalsIgnoreCase("Parallelogram")) {
          return new Parallelogram();
     }
     return null;
     }
}

Something I’d like to add on the subject is perhaps it would be a good idea to develop an enumeration type to define the names of the above given shapes as constants. Also, based on the fact that we are offering a way to create objects here, I would have to say that the factory design pattern is a creational one as well, along with Singleton.

Last but not least, Subham describes the decorator design pattern as one commonly used in Java. The idea here is to “add new functionality to an existing object without changing its structure.” Thus I would have to agree with Subham that this design pattern seems to be a structural one. I do not think we’ve discussed this in CS-343 yet, but I remember using the decorator pattern in a previous course, so I see how it can be useful.

I feel that Subham provides great examples that have helped me better understand these design pattern concepts. The code he provides is well detailed and easy to follow. His blog will be a good reference to me in future projects during my professional career.

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

https://nikic.github.io/2011/12/27/Dont-be-STUPID-GRASP-SOLID.html
This week we analyze why a code may be STUPID. What makes code STUPID are the following:
Singleton
Tight coupling
Untestability
Premature Optimization
Indescriptive Naming
Duplication
Singleton, what is wrong with that? According to the example code provided in the article, the singleton allows access to the DB from anywhere using the getInstance() method. In addition, it ensures that there is only one database connection at a time. This is not an issue until a second connection to a different database is needed. In this case, when the application grew larger, the developer needed to change the singleton to have a getSecondInstance(). However, this isn’t a singleton anymore. Another issue is that the getInstance() function binds the code to the DB classname. This means that the DBclass can’t be extended. In this case, when a developer wants to optionally log query performance data to the APC, tight coupling to the class name will not allow it to do so. Dependency injection would have solved the problem, however this is not allowed in singleton pattern. What the writer introduced was what can be called a “hack”, but this is bad coding practice. The last point to be disappointed in is that the getInstance() method allows global access from anywhere using the DB. However, in PHP we learned to avoid the use of the global keyword. Global instances in singletons creates non-obvious dependencies, making the app harder to reuse and test. So, this is impractical coding practice.
The singleton issue can also be generalized to the issue with static methods and properties. For example, the Foo::bar() method will tightly couple the code to the Fooclass. This prevents the Foo function from being extended. This makes it harder for the code to be reused and tested. The example provided is the House class with the constructor function for the variables door and window. The question to ask is how would you replace the door or window in the house class. The answer is you can’t! Instead, the dependency injection can be introduced, however the House class is an example of stupid code.
Finally, we stop at the U in STUPID which stands for untestability. Unit testing is important and if we cannot test we cannot verify its proper functionality. If we don’t test we can end up with broken code. Making a code hard to test is in this case stupid code. What makes a code hard to test? — tight coupling. Dirty hacks can be used to avoid these issues, but we would rather not have broken codes in the first place. Overall, good coding practices means that it can be easily tested.
I chose this blog post because it introduces the disadvantages of the singleton design. This further intends what I have learned in my first blog post on Singleton patterns. Singleton in this case is criticized even for its advantages in creating a global state for a single instantiation. In this case, it is criticized as stupid code because it does not allow the developer to extend the code without modifying it to include a second instance, making it a dupleton.
I chose to learn about STUPID coding practices in order to improve my own coding practices as a developer since it provides good examples for how to avoid bad code and how to improve upon it. By, following some of the guidelines introduced here, this helps to make the code easily extensible without modifying its previous functionalities.

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