For this blog I chose an article on DZone which is basically an online community for software development. I discovered them through the UML exercise in class because of their “refcard” we used as a guide. For the article, I went with “Decorator Pattern Tutorial with Java Examples” because I wanted to learn a design pattern I’d never heard of. Also, with Java examples it would be easiest to follow along for me.

To get started, it’s important to know that the decorator pattern allows class behavior to be extended dynamically at run-time. This means attributes can be added to Objects dynamically which the author relates to the concept of a wrapper object. The decorator pattern is more broadly considered a structural pattern which encompasses many different patterns that focus on identifying a simple way of implementing relationships between entities.

One of the principles of the decorator design is that classes should be open for extension but closed for modification. Two main instances which the decorator pattern is useful are 1) when object behavior should be dynamically modifiable or 2) when concrete implementations should not be coupled to behavior. While sub classing can achieve the same effect, decorator can decrease maintenance by preventing too much sub classing. The author suggests to only use the open/closed principle where code is least likely to change to avoid making the code too abstract and complex.

A good example of the decorator pattern would be a company’s email system. If an email is generated and sent out from a company employee the decorator pattern could account for different scenarios. If the email is sent internally nothing occurs, but if the email is sent externally the system could “decorate” the email with a copyright or confidential statement attached to it.

After reading about the decorator pattern I can see the benefits but I don’ t think I have come across a project thus far that I would have really been able to put this to use. After a quick google search it looks like Java’s I/O streams implementation is a good example for learning more about the decorator pattern. I will probably look more into this as I can’t see how this article really helped me much moving forward. I think after I play around with it I’ll be able to better understand how I could apply it to my own projects. This article was good for a general explanation but not for learning the actual implementation.

From the blog CS@Worcester – Software Development Blog by dcafferky and used with permission of the author. All other rights reserved by the author.

Writing Great Unit Tests

Unit testing was one of the types of testing that I had played a little bit before. Therefore, when I found this blog entry about Writing Great Unit Tests: Best and Worst Practices, I decided to choose it to understand more about unit testing and check if all the unit tests that I wrote in the past were good or bad. Below was the URL of the blog entry:

http://blog.stevensanderson.com/2009/08/24/writing-great-unit-tests-best-and-worst-practises/

In this blog, Steve Sanderson discussed about unit test and the tips to write great unit tests. He mentioned that it was overwhelmingly easy to write bad unit tests that add very little value to a project while inflating the cost of code changes astronomically. In his opinion, unit testing was not an effective way to find bugs or detect regressions. Unit testing was more about designing software components. He also compared good unit tests with bad unit tests, and provided some tips to write great unit tests.

Steve explained the reason he thought that unit testing was not an effective way to detect bugs or regressions. I agreed with him that only proving component X and Y both worked independently did not prove that they were compatible with one another or configured correctly. Therefore, bugs still might occur when the application was run. This absolutely reduced the effectiveness of bugs detection. Before reading this blog entry, I never realized that unit testing was not that suitable to find bugs like that. Furthermore, Steve provided a table to identify which type of test we should use for different purposes like finding bugs, detecting regressions, or designing software components.

Steve also gave some tips about writing good unit tests. In my opinion, some of them were very basic, but Steve still included them. I thought that was because he saw a lot of bad unit tests had those mistakes. He recommended not to make unnecessary assertions because unit tests were a design specification of how a certain behavior should work. Including multiple assertions only increased the frequency of pointless failures. Moreover, the unit tests’ names should be clear and consistent. Personally, I liked the way he used to name the example unit test. It helped you quickly identify the subject, the scenario, and the result of the unit test. This way of naming was more descriptive than the way I always used. I would apply it the next time I wrote tests.

From the blog CS@Worcester – Learn More Everyday by ziyuan1582 and used with permission of the author. All other rights reserved by the author.

https://www.codeproject.com/Articles/307233/Singleton-Pattern-Positive-and-Negative-Aspects

Seeing as we’ve started learning about design patters in class recently, I decided I’d explore a pattern further in depth.  Seeing as the singleton pattern was the last covered in class it was the one I chose.  Where most other sources would just condemn it as a bad practice, the article linked above does a good job of exemplifying both the pros and the cons of using the singleton design pattern.  One of the pros, something I learned as well, was how singleton classes can save memory by using lazy instantiation.  Opting not to assign memory to the variable until called; this method can create errors as well.  If multiple threads access the instance at the same time it will create multiple instances of the singleton class.  There are synchronizing techniques to get around the issue but it’d most likely be easier to use static initialization.  In static initialization, memory is allocated when the variable is declared.  The only difference this makes in the code is moving the creation of the object to where the variable is being declared.  Inheritance with singleton classes seems straightforward enough.   Any class inheriting from it will create more than one instance of the class thus violation the principle that only one instance can exist. However, if you wanted multiple singletons to inherit the same behavior, the code could be provided in an abstract class.  Although this may seem purely a shortcoming, it does prove itself when compared to static classes inability to work from interfaces.  One of the other major drawbacks that I learned about was that singleton classes couldn’t accept parameters which contributes to their limited flexibility.

The singleton pattern has me a bit conflicted with its use in java.  Although it seems like an easy way to create global variables in java, many of its drawbacks seem very limiting or painstaking with more complicated programs.  The linked article does, however, do a great job of showing and explaining how to create singleton classes and will differently be my go to for a reference.  Reading it was a great auxiliary to the lectures given in class.  Seeing how singletons work (and don’t), in depth, has also raised my confidence with working with them.  I’m sure that having a complete understanding of this design pattern will be useful as a tool to compare and understand the behaviors of other patterns.

From the blog CS@Worcester – W.I.P. (Something catchy) by aguillardcsblog and used with permission of the author. All other rights reserved by the author.

Today’s blog post is about the Strategy design pattern. I found a blog on the Strategy pattern called “Design Patterns: Strategy”. This blog talks about the pattern, what it is, and how to implement it. The Strategy pattern is a way to get classes to interact nicely with each other, and keep code somewhat clean and manageable. The author of this blog uses the video game Overwatch as an example to showcase how the Strategy pattern works. In the Overwatch game there is a superclass Player, and Player has many attributes. In this demonstration, the author labels these primary_ability, secondary_ability, and ultimate_ability. These are all subclasses to the superclass Player. This seems like a pretty simple relationship that is easy to manage, which is true until you find out that there are 21 forms of playable characters. This, in essence, means that now all of those classes get multiplied 21 times. This makes code very labor intensive and difficult to organize. There should be a way to connect each of the 21 different character classes to only one primary_ability, secondary_ability, and ultimate_ability classes; rather than write those classes out 21 times. Additionally, each of the 21 classes would have to be overriden to cater to the different character classes. To remedy this, the author creates a series of classes (or “Strategies”) to keep from having to write out the classes 21 times, uniquely each time. Now, each version of the character class can inherit the Strategies, which hold the basic methods, and tailor them to the specific character by overriding them. Then, the character gets passed to the Player class. In the end, the Player class just gets passed a character, without having to know any specifics of attributes.

I chose this article because we just finished learning about the Strategy pattern in class, and we have an assignment coming up which uses this. I want to fully understand this before I take on the assignment, because I want to do the assignment correctly. The Strategy pattern is a rather straightforward software design, but it is extremely effective. I think that this reinforced my understanding of the Strategy design, and helps me to clearly see how the classes relate to each other. Before reading this article, I had a good understanding of the pattern, but the examples presented in this article helped me really get what the Strategy pattern is all about. I hope that now I will be able to implement the Strategy pattern without any issues, when dealing with a parent classes that have a multitude of similar subclasses.

Here’s the link to the blog:

https://www.madetech.com/blog/design-patterns-strategy

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.

Today, I am going to review and summarize Episode 283 of Software Engineering Radio.  This episode’s guest was Alexander Tarlinder, author of “Developer Testing: Building Quality into Software”.  The topics covered in this episode are quite relevant to the other posts I have done and one of those topics is specification based testing, which we have discussed in class.  I also selected this episode as the subject of this post because Alexander provides tips on how to test software effectively, both as a developer and as a tester.  The episode begins with Alexander providing an explanation as to why he wrote his book – he felt there were gaps within the software testing literature that needed to be bridged.  He claims that much of the existing literature on software testing will often focus too heavily on documentation, focus on a specific tool too much, or leave out crucial information on what to include in your test cases.  This can be hard to relate to for developers.  He defines general software testing as a process used to verify that software works, validate its functionality, detect problems within it, and prevent problems from afflicting it in the future.  He defines developer testing similarly but with the caveat that developer testing more systematically tackles the hard cases, rather than the rigorous; this is a result of developers being knowledgeable about the programming techniques implemented and the inherent bias that accompanies that.  Alexander argues that bias possessed by developers necessitates the need for additional testing to be performed by unbiased testers.  He insists that it is still necessary for developers to perform their own testing, though.  By performing testing during development, it ensures that at least a portion of testers’ workload will be a more of a “double-check”, allowing them to focus on the rigorous and unexpected cases that developers might overlook.

Alex then summarizes the main points of the discussion and provides tips on how to improve software testing.  The conversation strays a bit, so here is my summary and what I took from it:

• Encourage developer testing – Developer testing is a necessary practice to both ensure that the finished product is of high quality and functional and to allow testers to work rigorously, which will detect and prevent any potential problems in the future.
• Adopt an Agile development strategy – Agile development allows for rapid delivery of product and forces developers to adhere to effective working practices.
• Write code that is testable – Consider a Develop by Contract(DbC) approach where the caller and the function being called programatically enter into a “contract” with one another.
• Learn various techniques – Specification-based testing is a fundamental testing technique to learn, but it can sometimes lead to an approach that is too focused on where the data is partitioned, neglecting the in-between cases.

I think that this discussion contributed to my knowledge of effective development and testing practices which will help me a great deal when it comes time to implement them in the field (or an interview).

This blog post(2/9) is part of an assignment for the Fall 2017 session of CS443 @ Worcester State University.

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

We’ve been talking about path testing in class, such as tracing the concepts and expected behaviors of our code through a series of program graphs. I wanted to learn more about the different variations of path testing, and I found a good blog regarding this topic.

EngineYard: Ben Lewis – Happy, Sad, Evil, Weird: Putting Use Case Planning Into Practice

According to Lewis, happy path testing is one that developers take when testing for expected behaviors. But Lewis states it is imperative we take unexpected actions into account as well. Rather than solely thinking like a developer, we should be also thinking like an end user; the “actors” who are going to be using our finished products.One way of evaluate a myriad of action-consequence scenarios an actor may encounter is to follow a series of testing paths:

The Sad Path
In Lewis’ blog, he describes the “sad path” as one we should follow when we are testing our code.  He suggests it gives us insight on what should happen when an “actor” does something we don’t intend the person to do. If a user submits invalid information for example, we should run tests to determine that we are providing an appropriate response to this. This may include highlighting why the information is invalid, and prompt the user to reenter something that is valid instead. I feel that the significance of “sad path” testing is to ensure that our projects are as user-friendly as possible.

The Evil Path
When we take the “evil path” approach, we ought to be putting ourselves in the mindset of a malicious actor. For instance, we should run tests attempting to infiltrate sensitive information that we expect to be secure.  I believe “evil path” testing is important because we should have our users privacy and security in mind when developing our projects.

The Weird Path
Lewis suggests that taking the “weird path” is when we look for problems that may occur beyond our control. For instance, perhaps a portion of our project needs a certain server to be active in order to function properly. In this case, we should test that our program is appropriately detecting that the server is online, and if not, perhaps we can redirect the actor to an user-friendly status page to inform the user when the server is likely to be available.

The Happy Path
Last but not least, we should test the “happy path,” which can be described as ensuring that our project is behaving as intended. If our code has a submit form for instance, we should ensure that our code is submitting the information appropriately.

My main takeaway from Lewis’ blog is that the end user (actor) does not always interact with our projects in a manner that we may expect. Rather than simply testing expected behaviors, I feel we should evaluate possible unexpected behaviors that an actor may choose to do as well. I intend on doing this during my professional career when testing future projects.

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