The State Behavioral Design Pattern is one of the GoF Design Patterns. In his series on the Gang of Four design patterns, John Thompson wrote an article on the State Pattern, which he defines as “an important pattern that allows an object to change its behavior when it’s[sic] internal state changes.”

He opens the article by providing an example of a Vending Machine program that will need the State Pattern to be applied to it. One thing I like about the way he writes his examples is how he uses variable names to make it very readable. He could have just had the states as the integers themselves, but his simple and clever use of variable names has given me ideas of how to make my programs more readable in the future.

In order to transform his Vending Machine program from a “monolithic class” into a more adaptable program, John shows us how to implement the State Pattern. He separates each of the four states of the vending machine into their own classes. They each implement an interface that defines the behaviors of the vending machine. These state classes each detail how they handle the behavior in that state. Finally, the vending machine itself which handles the inventory of the vending machine and has methods a lot of methods to handle changing the state of the machine.

Due to designing the code with this pattern, you can add a new state by creating a new concrete class and modifying the vending machine class to handle it. However the currently written states are closed to modification as well, following Open Closed principle. When you compare the example before and after the State Pattern was applied, it becomes apparent why it is so beneficial to use this pattern when it’s appropriate: it makes your code more open to modification and more easily-understood. You don’t have to spend as much time reading and understanding code under the State Design Pattern, and so it helps make your program easy to maintain, especially when multiple people might be going back to the code later. Having more classes isn’t necessarily a bad thing.

From the blog CS@Worcester – Let's Get TechNICKal by technickal4 and used with permission of the author. All other rights reserved by the author.

The article I chose to cover for CS-443 this week is a research article titled Decision Graphs and Their Application to Software Testing by Robert Gold. This article goes in-depth on one of the subjects covered in our Activities, DD-path testing, as well as other decision-based testing methods. One of the things I like about this article is that it uses a lot of mathematical notation and logic to represent how the methods work. It also has very detailed proofs to show why the necessary branch/edge coverage is reached. There are several different examples of code that have corresponding decision graphs, to show the different parts of making a decision graph.

Looking at the example of the function f1 given in the article (Figure 3), there is something this article did with DD-path graphs that we did differently in class. whereas our DD-paths were just all the nodes in between with an in-degree and out-degree of 1, when Robert combines several D-nodes into one DD-path, he includes the first node that has an in-degree of 2 and the last node which has an out-degree of 0 along with the rest of the nodes. Therefore, his DD-Path graph for f1 is a lot simpler than what we would have made doing what we did in class. I’m curious which way is better. The article also dives into a topic about path testing we discussed but did not have an example of, that is when code branches into multiple different endpoints. In order to achieve branch coverage in these examples, you have to have multiple tests with different inputs that satisfy every branch.

Overall, the abundance of examples in both code and their associated graphs, as well as the very clear mathematical notation and rigorous proofs makes this article a really interesting read if you are a Mathematics major/minor. The conclusion at the end details a major application of this are modeling programs with flow graphs to represent programs. There are many different kinds of decision based testing methods that you can use, and if you have any questions about one of them or how they work, this is an amazing resource.

From the blog CS@Worcester – Let's Get TechNICKal by technickal4 and used with permission of the author. All other rights reserved by the author.

Greetings reader!

Today’s blog,  will discuss the differences between static and dynamic testing. I will be briefly explaining the benefits for each test, as well as pointing out their distinct features. I will also be sharing my analysis of Software Testing Help’s-” Static Testing and Dynamic Testing – Difference Between These Two Important Testing Techniques” article from which I read. Without any further babbling, let’s start.

Static testing is a testing technique that takes the form of design reviews, functional requirement reviews, code walkthroughs, business requirement reviews, and test documentation reviews. It is a ongoing activity that is not just done by testers.

In static testing, code is not executed; instead it checks the code, requirement documents, and design documents to detect errors.  The goal of this technique is to improve the quality of software by finding errors in early stages of development. Static testing is often called as non-execution technique or verification testing.

Static Testing Techniques:

• Informal Reviews
• Technical Reviews
• Walkthrough
• Inspection
• Static code Review

Dynamic testing is more hands-on and develops on the product itself and not on an a representation of the product. A much formal process of test cases, considerations, and execution explain the dynamic testing methods. Dynamic testing is when you are providing an input, receiving an output, and comparing the output to the expected behavior. It is a system made with the intent of finding errors.

In dynamic testing, code is executed. It checks for working behavior of the software system, memory, and the performance of the system. The goal of this technique is to ensure that the  product works in agreement with  the business requirements. Dynamic testing is used at all levels of testing and it can be either black or white box testing. Dynamic testing is also known as validation testing.

Dynamic Testing Techniques:

• Unit Testing
• Integration Testing
• System Testing

In conclusion, both static and dynamic testing reveal mistakes and coding errors using different methods. Verification (Static) and Validation (Dynamic) are two measures used to check that the software product meets the requirements specifications. Together they try to help improve software quality.

Software Testing Help’s-” Static Testing and Dynamic Testing – Difference Between These Two Important Testing Techniques” helped me a lot when reading about Static vs Dynamic testing.

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

In this Apprenticeship Pattern “Craft Over Art”, it explains the relationship between the craft and the art of a craftsmen’s work. As an apprentice, it is important to understand how much of an impact both aspects have for the work that they produce for their customer. In the software development field, most of the work that you would produce would be for the customer or client that requests the product. With this being said, the customer or client that requests the product will have certain specifications that they want you, the craftsmen, to make, or they could ask for you to make a product that is useful for them.

“Craftsmanship is built upon strong relationships. Focus on delivering value to your customer over advancing your own self-interests. As a craftsman you are primarily building something that serves the needs of others, not indulging in artistic expression. After all, there’s no such thing as a starving craftsman. As our friend Laurent Bossavit put it: ‘For a craftsman to starve is a failure; he’s supposed to earn a living at his craft’. You need to do your best work in ways that place the interests of your customers over your desire to display skill or pad your resume, while still adhering to the minimum standards of competence provided by the software development community. Walking the Long Road means you must balance these conflicting demands. If you starve because you are too much of an artist and your creations are too beautiful to be delivered in the real world, then you have left the craft. If your desire to do beautiful work forces you out of professional software development and away from building useful things for real people, then you have left the craft.”

This idea of deciding craft over art is understandable and this idea stood out to me the most. The software that you make as a software developer must be useful to the customer, otherwise it is a meaningless piece of work.  It is okay to implement the special touches on your work once it has fulfilled its usefulness to the customer and their needs. However, it is not okay to primarily focus on the art aspect over the needs of the customer. You are called craftsmen for a reason, not an artist, and that’s how I view this pattern’s main idea. I completely agree with this pattern’s idea of craft over art and I feel that every software developer should consider the “craft” a priority over the “art” of their work first.

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 the apprenticeship pattern “Learn How You Fail”. To quickly summarize, this pattern asked you to stop looking at your successes and start actively seeking your failures and weaknesses in order to learn from them. I really liked the message behind this pattern because it is different from what we are accustomed to. It is normally very easy to focus on getting better at something you are mediocre at, and even easier to focus on getting better at something you are great at, but it is really difficult to confront your shortcomings and approach what you are terrible at. My interpretation of this pattern was that it doesn’t seek to discredit the good aspects of your skills but rather putting a focus on the bad as to make you a better engineer overall.

This is another applicable pattern for me personally because I still have a few areas of weakness in my development skills, even in some of the technologies and languages that I’ve been using many years. I have caught myself opting out for a simpler but worse performing option because I didn’t want to confront an area of weakness needed to implement the better solution. The other key aspect of this pattern in accurate self assessment, asking yourself “am I really this good at X, or is there major room to improve there”. I often find that we normally give ourselves the benefit of the doubt and say “Yes we are that good”, and this closes out any potential opportunities to actually improve. What this pattern teaches is to really ask and assess deeply and even ask for an external opinion (via peer review) for areas of weakness.

I agree with this pattern and I plan on implementing this going forward in my career. This pattern should be fairly easy to apply because of its practicality. If you are weak in a skill that will no longer needed, the pattern suggests that you shouldn’t waste your time with that and focus on more important areas of weakness. The only challenge to applying this pattern will be the reluctance to do what we are not good at, but I believe that overcoming this will be much easier if we think about the benefit that will come from fixing our weakest links.

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