Mutation Testing

Greetings reader!

The nature of this blog is to give a short summary over a topic that is essential in the Computer Science field: Mutation Testing. This blog will share my analysis of Tutorial’sPoint’s: Simply Easy Learning- Mutation Testing Tutorial.  I will be expressing my reaction to the content by sharing what I find useful and interesting and displaying if I have any concerns or disagreements. Without any further introduction, let’s begin.

First, let’s start with defining what mutation testing is. Mutation testing is a testing technique that uses the structure of the code to conduct the testing process. It is simply the rewriting of code in small ways in order to take out the excessiveness in the code. This wordiness may cause failures in the software if it is not altered. It is very sneaky because it can pass through the testing process’ unnoticed.

There are three types of mutation testing: value, decision, and statement mutations. Value mutations are efforts to change the values to display errors in the programs. The change of the value is usually to either a very large value or a very small value. It is found that the most common strategy to combat this is to change the constants. Decision mutations are when the code is changed to check for errors in the design. Ways to fix these errors are by changing the arithmetic operators to find the failures or by altering the relational and logical operators. Statement mutations are when changes are done to the statements by deleting or rewriting the line.

Mutation testing is based on two theorems. The first is the competent programmer theorem. This theorem explains that most software errors made by experienced programmers are due to small syntax errors. The second theory is called the coupling effect. The coupling effect says that simple errors can couple to form other faults.

All in all, mutation testing is a fairly simple technique that is used when testing code. Sometimes errors or faults can be hidden when making tests that will cause the source code to fail. Mutation testing is the process of altering these subtle errors in efforts to run the code.  This topic is extremely important to this field because it gives us a deeper understanding of our errors, which helps greatly when correcting “bad” code.

Source: Tutorial’sPoint’s: Simply Easy Learning- Mutation Testing Tutorial

 

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

The Simple Factory – Easy as Cake?

Using the Simple Factory design pattern is a lot like making cheesecake

Software developer Sihui Huang, writing for the blog freeCodeCamp, explains the simple factory design pattern in terms that most people can appreciate – cheesecake.

Huang walks us through the basic steps in a simple factory for creating cheesecake. Starting with a number of his favorite types, he creates a makeCheeseCake() method which calls cheesecake.makeCrust, cheesecake.AddLayers, etc. The makeCheeseCake() method uses the type of cheesecake as a parameter, and calls the the steps to creating a cheesecake that all different types have in common. No matter what kind of cheesecake you are making, you still need to make the crust. So the makeCheeseCake() method is only concerned about the steps required in making any kind of cheesecake, it doesn’t care about what flavor the particular instance is. Huang describes this concept, as we have in class, as encapsulating what varies.

So Huang goes on to create a cheesecake factory class that handles all the different classes of cheesecake we can possibly create, and returns the appropriate cheesecake type by a createCheeseCake() method inside the factory class. The trick is that when you call the makeCheeseCake(), a new cheeseCakeFactory object is created, and uses the createCheeseCake method to determine what type the cheesecake is. So now the MakeCheeseCake() method does not need to know at all about what kind of cheesecake it is creating.

By separating the parts of a program that stay the same from those that vary, we can simplify adding and modifying different types of an object (in this case cheesecake) by adding a new class and adding to the cheeseCakeFactory class. No code has to be rewritten to accommodate for changes and removals of types of cheesecake.

Personally I enjoy Huang’s analogy to elaborate on the simple factory design pattern. Being able to separate varying parts of a program from parts that never change makes our code more understandable, coherent, and easy to modify. And the idea that a “factory” can handle the details of initializing different types of objects instead of having separate implementations for every object type is good design, and I think the cheesecake factory example is a good metaphor for encapsulation

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

The Differences Between Black Box, White Box, and Gray Box Testing

For this week’s blog post, I chose this blog by Lucie Saunois. It talks about the differences between Black box, Grey box, and White box testing for software or applications.

Black Box Testing

Black box testing reviews only the functionalities of an application. Testers do not really know the internal structure of the application. Testers typically have a “user” profile. This method aims at checking if the final stage of the application works like its supposed to. Common things the tester would look for in a Black box testing are missing or incorrect functions, interface, performance, program initialization, and external database access errors. To do this test, each different user has their own scenario to test, and all functionalities must be tested.

White Box Testing

White box testing reviews the functionalities of an application as well as its internal structure.  All of the internal components of the application are tested through the source code. Testers have a “developer” profile and not a “user” profile unlike in Black box testing. White box testers need to have competence in programming since they need to understand the source code. It is mostly done in the developing stage of the application. Therefore, it allows them to test the data flow and the handling of exceptions and errors. Scenarios for this test are created by the testers based on the source code. Testers only check if the code produces the expected results.

Gray Box Testing

Gray box testing is a compilation of both Black and White box testing. Gray box testing tests both the functionalities and the function of an application. In this test, the testers know the functionalities and also the internal structure of the application, however, they do not have access to the source code.

 

This blog explaining the differences between each kind of testing is really easy to follow. The way they were describe was easy to understand. She also wrote about their benefits and drawbacks of each method of testing. I really find her examples interesting towards the end of the blog where she uses an analogy by comparing it to testing a car system. I think finding blogs like these would help anyone understand the different testing methods out there, it is simple but very informative.

 

 

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

Stick to the Plan Stan

               Coding is at its very core an art piece. If we think of coding as a work of art why is it that some people expect to sit down and code a “master piece” in one sitting without thinking about what they want to code. True art take meticulous planning; sketches, rough drafts, concept art, and experimenting are things that make paintings and art so perfect in their final form. What needs to be don’t to make a programmer an artist?

                Well with our recent focus on UML diagrams it got me thinking about a similar planning stage to coding like that of an artist. After all UML diagrams show code as an image and flow chart in an eye pleasing way. With a bit of research I found that a lot of coders, and teachers believe that planning before writing code is much more effective than just trying to get it done as you go. I stumbled upon Khan Academy which is a website that I have always respected and thought highly of. Anytime I have problems or questions with any subject Khan Academy was always my go to for information. When I saw that Khan Academy actually had a lesson plan for how to set up coding before writing any code I was intrigued. Turns out like their other lesson plans the steps were all set up clean and backed with reason to why this strategy works.

 

Khan Academy laid out these steps that I believe when thinking about your coding structure can really help:

1. What do you want to make?

2. What technology will you use?

3. What features will it include?

4. But what features must it include?

5. How will you implement it?

6. What’s your timeline?

                I believe planning is important to the success of your code. The examples that Khan Academy use look similar to a mock UML diagram. You come up with the function each class will need the variables, and don’t implement them, but rather conceptualize what your code should do. The author offers a sample of what the concept would look like. Disregarding abstract and interface classes the layout would be easy to transfer to a simple UML rough draft.

Objects

  • Brick (.isHit())
  • Paddle (.move())
  • Ball (.move())

Scenes

  • Start
  • Game
  • End

Logic

  • Ball-brick collision (function, use bounding box)
  • Paddle-ball angling (function, invert angle)

User interaction

  • Keyboard-paddle movement (keyPressed)
  • Buttons for scene changes (mouseClicked)

User data

  • Ball deaths (array)
  • Ball hits (array)

In the end I think the information we are learning about UML Diagrams, and keeping neat and organized work flows is vital to thinking about planning out your code. Create a plan and stick to it Stan.

 

-Computing Finn

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

Qualities that Make a Good Tester

Everyone want to be good at their job. But what’s make they good at it, especially in software tester. I came on a list “10 Qualities that Can Make You a Good Tester” on a blog website. The blog points out 10 points of what make person is a good tester, though the rich experience in the industry by the author. Other than the obvious, tester make sure the code work correctly, there are more to it. Tester need to have the overall look on the project, why the code work and not work. What is the cause and how it effects the consumer and developer.
I thought understand priorities is very important. Tester usually have the list of tests to check, but they need to know which test is important and and plan to doing it. Ask question, to understand the overall picture, I learned that though my project at school. When we look at the code the setup by others, there will be questions on what they mean by it. Team player and good communication is great for tester, we always have connection to the developer and consumer. By understand problems easily, we can be more effective, save time and money. Positive attitude is also important, overall job of tester is to help others. This is not just applying to tester, but to overall everyone, though positive attitude we can make the production better overall. The last progress of tester usually is report, tester need to have detail and easy to understand on what the issue of the application. Think of the issue not just how it effects the project, that tester assign to, but on how it effects on the real-world application. From the point of view as end-user. This is good list on overall what make testers good. We need to keep these points in mind, in any computer career. It will help us on long term.

Link to article

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

Your Interfaces Are Your Responsibility

This week, I looked through the Google Testing Blog and spotted a great post regarding your job as a programmer in writing good interfaces. I thought it touched on some great points and used some great examples, so here I am, writing about it. The blog post is part of a series of posts from Google called “Code Health”, which essentially outlines some of their standards for code quality.

“Code Health: Make Interfaces Hard to Misuse” uses an example of an empty Vector which has a “num_slots” slots available for use. Marek Kiszkis, the author, outlines two ways to write this class. The first way relies on the person who implements it to manage the expansion of the number of slots of the vector. They must check the slots remaining before adding into it to ensure that it has the room for a new item. The second way the Vector class is written has the Vector automatically expanding by a certain number of slots as items are added in. The implementer has very little control over the function of the Vector, however the Vector’s lack of flexibility can be a desirable outcome, as misuse much more difficult. The author provided a few different examples beyond this of easy-to-misuse Interfaces, such as requiring the caller to run initialization functions, perform cleanup, etc.

The article is finished off with a reminder that, while making interfaces this way is a good thing, you still need to be selective with this methodology. Sometimes writing an interface in a “overly-defensive” way will result in needlessly complex code, where implementation is more difficult to execute than necessary. The documentation is equally as important as the structure of the code, and keeping that in mind will help you write usable, stable, and effective code for others to utilize.

I found this blog post surprisingly relevant to my current course-load. In both this class (CS-443) and the Software Architecture & Design class (CS-343), will be implementing interfaces much more frequently than we have in previous courses. Having a better understanding of safe and effective ways to writing them will be extremely useful in the long run.

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

Blog 3 CS 443

My blog this week is about an article which talks about things that could possibly go wrong while discussing about testing and how someone could improve their testing. In the article, the author points out several flaws which many testers tend to make. Some of these mistakes testers make include things such as caring about how many tests there are instead of the quality of the tests, how many people have a hard time adapting to creating new tests as a test case evolves and when people believe there is only one way to test something.

I thought the author had a lot of good reasoning behind his thoughts on testers, which can be applied to more than just testers too. This applies especially to his first point which pertains to when people care more about the volume of test cases they have written versus the quality of those test cases. The author’s point, which I agree with, is that it does not matter how many test cases you write, if they do nothing to actually test the code, than they are completely useless. This thought also makes me want to pay more attention to the test’s that I write to make sure that they are effective and proper to what I am actually testing for. Another comment the author made which makes me want to look more at the way that I move through testing is that many people have a hard time adapting their tests as the strategy of said tests changes. Being able to change and adapt your tests as the test strategy changes shows a true understanding of the purpose of the testing that is happening. Finally the author brings up the point that people often have the thought that if they are testing something one way, they have tested that thing fully. However, if they run the same test with a different data set they could discover some new bug that you would not have seen before. This is another good example by the author of pointing out a flaw that many people can and tend to make, and one that I plan to focus more on myself.

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

Blog 3 CS 343

My blog this week will be based on this article that argues that a certain form of testing, “lean testing”, is far more helpful than something like normal unit testing and test driven development. The author goes on to explain their way of testing, “lean testing”, is essentially focusing on different kinds of tests then unit tests which will be more beneficial with the finite amount of time you may have to get certain projects done. With unit testing, you tend to test bounds of the program that will affect very few users and it is better to focus the tests on more real world scenarios that a user might encounter.

I feel the author raises a good point in this testing, to focus tests more on what a user of a program will likely run into rather then on the bounds of the program which very few to no users will encounter. With that though, I do still feel it is important to at least include some tests to make sure the bounds of a program are working and will notify the user of such. Another thing that the author included was the three dimensions they think best help to follow in testing and that is speed, cost, and the most important one; confidence. This quote from the article which I feel reflects what the author is trying to make clear in the article is from Kent C. Dodds, who said “The more your tests resemble the way your software is used, the more confidence they can give you”. The author also provides another reasoning for this testing of what the user is more likely to encounter when using the program, and that is that testing those cases tend to cover more of the code then something such as boundary testing. One final point that the author brings up that I think helps reinforce their way of “lean testing”, is that unit test code is often not resilient to code changes. While some of the test code may be reusable, most of it is often not.

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

Designing the code is more important than you thought

Personally, I always think that the design phase of a program is very important and it should be done almost immediately after I started setting up my git project. Like all other new developers, at first, when me and my cousin were working on an Android project, we thought it would be just a waste of time. Surely after a month, it started to really fall apart as we have all sort of problems like our implementations does not work well together with a lot of lengthy methods that is definitely not necessary to be that complex, and we even used some dependencies that are obsoleted just to make another piece of code compatible with the situation. We learned our lesson and from then, we developed a habit to jot down some idea and implementation to at least let each other and ourselves how we would carry out the project. I actually found this article months ago and I think it’s already pretty neat, so I decided to write my blog this week based on it.

For a start, this article is written by Marcus Biel and it mostly talks about what he called “Clean code”, which is basically the idea to have your code be precise and as close to perfect as possible, even though it is a small project. I really like the part where he says “If you have more code than you need, it shouldn’t be there. There shouldn’t be anything superfluous, and I go so far as to say that there shouldn’t even be superfluous whitespace. You want your code to be as efficient, readable, and maintainable as possible, and instead of only solving the problem.” This is probably what everyone should expect to achieve after finishing their “first draft” of the program.

Some would ask why is it so important to spend a lot of time on this phase. He gave two simple cases that are really relatable to programming. Imagine living in a house that was built without any blueprint and when it falls apart, you would not even know where to start to fix it and eventually, the roof caves in. For instance, when you have a shopping cart, of which function is to put things that you would buy into but people keep throwing trash into it until it spills out and you don’t know which one to put on the checkout counter. In these cases that he gave, it was really clear that there are no boundaries or rules to maintain your object and prevent it from long-term problems. The lazier you are at first, the more efforts you have to put in in order to have it up and running. Even if most of us are not perfectionists, this problem can’t be ignored as our projects would get more complicated the more we develop it.

Now that we know that it is critical, we can look at a few ways to accomplish clean code. The simplest thing that you have to do is to not think it as a coding project, think of it as a design and planning process. Let’s pretend that you are building a house. A strong foundation is what we really need and that can be seen from the coding aspect as file structure, classes, and methods without any bodies. When you have a solid foundation, it would cost fewer resources to maintain as it is already hard to fall apart and even if you want to expand, it is much easier to base on the old foundation, rather than having to build another one.

Not only a solid foundation that we need, but we also need the coherence, or should I say it is easy and makes sense to everyone who read it. The author of this article makes a point that we should follow the idea of “ubiquitous language”, which is to have your variable names, class names, and package names to make sense to whoever is reading your code. This design is called Domain-driven design. In addition to this, I also think that it is important to follow the naming convention, use detail unique name for variables and practice proper indentation so that myself and the one I work with can see the structure and what words mean without having to scroll up and down a lot.

Without any further reading, I think these pieces of information that I have given are quite enough to convince you to think and start to develop the habit to have a design phase before carrying out the project.

From the blog #Khoa'sCSBlog by and used with permission of the author. All other rights reserved by the author.

DRY over DAMP?

Ever since I picked up my first Java book and read through it, one thing always stuck in my mind when it came to writing any program and that is to not repeat yourself when you don’t have to. Leonardo Brito wrote an interesting piece, “Don’t obsess over code DRYness”, and he gave a few good points on why we shouldn’t try to make our code as complex as we can. He starts off by saying that we, as humans, are good at pattern recognition but sometimes we over-do it. He uses the example codes below:
____________________________________________________________________________
# Example 1
class Car
include Checkups

def maintenance_10k
check_break_fluid
check_battery_terminals
check_engine_oil
end

def maintenance_30k
check_break_fluid
check_battery_terminals
check_engine_oil
check_spare_wheel
end

def maintenance_50k
check_break_fluid
check_battery_terminals
check_engine_oil
check_spare_wheel
check_gearbox
end
end
____________________________________________________________________________
# Example 2
class Car
include Checkups

def maintenance_10k
basic_maintenance
end

def maintenance_30k
basic_maintenance
check_spare_wheel
end

def maintenance_50k
basic_maintenance
check_spare_wheel
check_gearbox
end

private

def basic_maintenance
check_break_fluid
check_battery_terminals
check_engine_oil
end
end
____________________________________________________________________________
After DRYing the code we see that it produces a new method called basic_maintenance while the original maintenance method conveys exactly what the method is expected to do. He then added a change such that we no longer need to check the break fluid on the 10 thousand miles checkup, so now we must remove the method check_break_fluid from basic maintenance and only add it to the upper maintenance methods. What he was trying to illustrate is that although one set of code was easier to read and follow, a simple change could have us altering out code in more ways than we’d like.

Brito talks about the trade off between some duplication over the wrong abstraction because overly DRYing your code could result in more confusion than simply repeating SOME code which is where he introduced another concept: DAMP – descriptive and meaningful phrases. The purpose of these two terminologies is to guide is to write better code and not going to any extremes.

I found that the concept of over DRYing your code interesting because I never thought about it that way and that there was a such thing. I’ve heard of DRY but never DAMP so I found that amusing how they’re opposite from each other. Looking back at my projects I feel as though I stand somewhere in between both concepts. I try to not over-do simplifying yet at the same time I make sure I apply DRY when necessary. I agree with what the author said about repeating sometimes to make it easier on yourself in the end.

Thank you for the read!

From the blog CS@Worcester – Life in the Field of Computer Science by iharrynguyen and used with permission of the author. All other rights reserved by the author.