https://www.softwaretestinghelp.com/code-refactoring/

Refactoring is the practice of improving code without changing the existing functionality. It is used to transform inefficient or complicated code into efficient and simpler code. Some reasons why a piece of code may need to be refactored are:

• Code smells – indications that serious problems may exist in the code. Some common code smells are redundant code, declared variables that aren’t used anywhere, over-complicated design, and the existence of too many complicated loops or conditionals
• Technical debt – when shortcuts are used that will require more work to fix later
• Following agile – agile software development promotes incremental development. If code is changed without proper refactoring, it may create code smells or technical debt

Refactoring code seems like something that only developers need to care about. However, it is something that software testers need to know about as well. When code is refactored, the addition of new code or updating of old code may cause existing unit tests to fail. As a tester, refactoring of code means that in-depth testing and regression testing must be performed. In-depth testing includes all existing user flows to ensure that all functionalities are working the same as before. Regression testing is required to ensure that upgrading a module did not break the functionality of another piece of code. Refactoring code may also cause test automation scripts to fail. When refactored code is tested, scenarios such as business cases, user flows, user acceptance tests, and the existing functionality need to be validated.

I thought this blog post was interesting because I have never thought about refactoring from a tester’s perspective. Even when small changes are made, a tester must make sure that the changes don’t break any other parts of the code or alter the user experience. Since refactoring is only concerned with making existing code more efficient or easier to read, tests should not return different results after refactoring. I learned a few useful terms from this post such as technical debt, in-depth testing, and regression testing. Reading this blog has given me a new perspective on code refactoring and has enhanced my understanding of the topic.

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