In the final exam, there were a few questions on mutation testing which I was very unfamiliar with so I decided to look into posts/blogs about mutation testing. One interesting blog I came across was written by James White – ‘Mutation Testing – Who will test the tests themselves?’.

The very first sentenced stated “this is aimed at people who are not familiar with mutation testing” and it was all over from there; I had been sucked into the article since I had no idea what mutation testing really was.

White starts off by describing what mutation testing really is and his definition was “Very simply mutation testing is a way of testing the quality of your tests by introducing changes into your code and seeing if your test suite detects them”. Very straight forward. He then gives an example written in java and a scenario seen below:

private static final int MARGARINE_WEIGHT = 100;
private static final int COCOA_WEIGHT = 25;
private static final int EGG_COUNT = 2;
private static final int ORANGE_JUICE_VOLUME = 15;

Cake createCake(CakeType cakeType) {
Cake cake = new Cake();
cake.setMargarine(MARGARINE_WEIGHT);
cake.setSugar(MARGARINE_WEIGHT);
cake.setEggs(EGG_COUNT);
if (CakeType.CHOCOLATE.equals(cakeType)) {
cake.setFlour(MARGARINE_WEIGHT - COCOA_WEIGHT);
cake.setCocoa(COCOA_WEIGHT);
} else {
cake.setFlour(MARGARINE_WEIGHT);
if (CakeType.ORANGE.equals(cakeType)) {
cake.setOrangeJuice(ORANGE_JUICE_VOLUME);
}
}
return cake;
}

As well as different test cases:

@Test
public void canCreateVictoriaSponge() {
Cake actual = testee.createCake(CakeType.VICTORIA_SPONGE);
assertEquals(100, actual.getMargarine());
assertEquals(100, actual.getFlour());
assertEquals(100, actual.getSugar());
assertEquals(2, actual.getEggs());
assertEquals(0, actual.getOrangeJuice());
}

@Test
public void canCreateOrangeCake() {
Cake actual = testee.createCake(CakeType.ORANGE);
assertEquals(100, actual.getMargarine());
assertEquals(100, actual.getFlour());
assertEquals(100, actual.getSugar());
assertEquals(2, actual.getEggs());
assertEquals(15, actual.getOrangeJuice());
}

He then shows us the results of his tests as well as his mutation tests. So I learned that mutation testing works on the principle that since the test code is there to ensure that the code works, if mutating a test, at least one test should fail. Mutation killed means all your tests pass and mutation survived indicates that the mutation survived and there is a potential area where a bug could arise.

As always, subscribe if you are interested in Computer Science ideas/technologies/topics!

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.

As I take my first step towards my journey in Software Quality Assurance and Testing I dive into Unit Testing. After searching the web found a really good podcast named “Unit Testing With Test Driven Development” by Beej Burns this podcast is about Unit Testing and focuses most on Test-Driven Development (TDD). I will be using this podcast to help me write this blog.

In the podcast they had two guess John and Clayton. They went on the podcast and talked about their book ‘Practical Test-Driven Development Using C# 7: Unleash the power of TDD by implementing real world example under .NET environment and JavaScript’. I personally have not read this book. According to the podcast this book is meant for Software Developers with a basic knowledge of TDD. This book is intended for those who wish to understand the benefit of TDD. This book is beneficial for individual who know C# basic since all the examples are in C#.

The Following Q&A are the Question asked in the podcast and the guest answer. The answer I am writing are summarized in my own words but originally derived from the guest on the podcast. Also I am not doing all the Q&A just the ones I found interesting and liked how the guest answer the question. If you want to hear the original question and answer visit the podcast site: https://completedeveloperpodcast.com/episode-140/, Lets start.

What is Unit Testing?

Unit Testing is the ability to test in isolation. That is to simply test an application without affecting the rest of the other test.

Why is Unit Testing important?

We use unit testing to make sure each unit performs as intended. Unit testing is important because it minimizes the risk of error in your software, but it also forces you to have better code structure. It also allows major changes in your code to happen at a lower risk. Another reason it is important is because it allows new developer to understand your software structure.

*Note that naming convention is very important so developers can understand what is being tested.*

What is the point of Test-Driven Development (TDD)?

The point of TDD is doing the right thing without making a mess. That is short iteration cycle reassuring that you and your application are doing the right thing.

According to one of the guests when writing Test-Driven Development there are 3 stages/steps:

• Red cycle to see test fail
• Green phase when you make the test pass
• Refactor production code and test code.

The idea of TDD is to build the test before the code.

Other benefit for TDD other than code in an organized level is:

• Reduces the overall bugs and make bug resolution quicker.
• Less down time.
• Better requirement
• Can find problems with just running the test which it shows where code went wrong.

What are some of the things people get wrong about unit testing and TDD?

Testing your test too close to your implementation. “Test should represent the business rules not how you decided to implement the business rule. That way when you go and change stuff later on like the implementation. You want to refactor and remove thing into a different class. This doesn’t break what your test does because you will be restructuring how it is doing it”.

How do you manage complexity on a unit test, and how do you structure your overall testing projects?

“Form an overall method uncle bob (Robert Martin) suggest only having method that are five lines or less in size”. The guest that answer this question take Robert Martin suggestion to heart. He goes on and explains that if a method has more then five lines then he’ll brake it down into more than one method. If a class has more than five method then he’ll brake that down into more than one class. If a folder has more then five class than he’ll brake that down into more than one folder. If a project has more then five folder he’ll consider braking it down into more than one project. He goes on and say that he will do the same exact thing when testing except he doesn’t care much about the line length because most test case are usually 3-4 lines long. He has the arrangement where he set up the pre-content of the test and then have the action are 1-2 lines. These tests are pretty small to start with but within a test class he won’t have more than five things overall that he is testing within a test class, no more then five unit, and no more than five logical assertion which tends to reduces the size of any one thing within a test project.

What are some good practices you can use to make sure your test is maintainable on the long run?

• “Don’t forget to refactor your test, because your test suit is just as important as your production code”.
• “Remember you are testing small unit or small pieces that should have never enter connective dependency so that you feel comfortable substituting a mock, spy, or fake implementation. Be careful not to test your fake, mock, or spy.”
• “Where ever the code end that’s where the test should end”.
• “Make sure we abstract all third-party code”.

I will wrap this up by saying unit testing is a very important skill to have no matter what. It helps in creating clean code and reduces the risk of error. Unit testing allows software developers to make large changes in the software code at a minimal risk rate and it allows code structure to be understandable by new developers. One thing to note is when creating unit test and developing software you must make sure to have good naming convention. When developing software, its best to start with writing the test first.

My name is Yesenia Mercedes-Nunez and this has been YessyMer in the World Of Computer Science, thank you for your time until next time.

From the blog cs@Worcester – YessyMer In the world of Computer Science by yesmercedes and used with permission of the author. All other rights reserved by the author.

In the second part of Brandon Gregory’s blog post “Coding with Clarity: Part II“, he starts with the assertion that “Good programmers write code that humans can understand”. In the spirit of clarity, Gregory continues to elaborate on solid design principles that are helpful in software engineering.

The first principle is the Law of Demeter, or as Gregory puts it “the principle of least knowledge”, and describes this principle as an application of loose coupling, another design strategy that states one part of a program should not rely on others. Adhering to this principle will help ensure flexibility if new features are added or modified.

An example Gregory uses that demonstrates this principle is the use of getter/setter methods to provide access to class data as opposed to allowing classes to directly access data. By applying this tactic, it ensures that future modifications do not mess up any other parts of your program, as all modifications will be in the getter/setter methods.

The next programming practice is the Interface Segregation Principle. This is to make sure no object contains methods it doesn’t use. If a class has a bunch of methods, and not all methods are used for each instance, the better strategy is to separate that class into specific interfaces or sub classes. This is a similar goal as the strategy design pattern that we discussed in class.

However, Gregory warns us that abstraction can be taken too far. It is possible to abstract so much that the program contains an excessive number of interfaces or sub classes. The author reminds us that the goal of abstraction is to reduce complexity.

The final principle in the article is the open/closed principle. This assertion is that software should be open for extension but closed for modification. If the program is designed correctly, the implementation should perform as specified and should not be modified. Instead, to change functionality of the program, all that should be done is adding functionality, and not changing any of the existing code.

I very much found this two part series of “coding with clarity” helpful.  Almost all of the principles Gregory explains have been applicable to content we have covered in class. I found his writing style easy to follow and the particular examples he uses to demonstrate the principles are cogent and illuminating.  I recommend them to everybody looking to improve their design knowledge.

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

Blogger Lukas Rosenstock posting for the company website BlazeMeter describes common API test strategies and definitions in his post “API Performance Testing Scenarios and Vocabulary“. While a good portion of the post examines how this particular software can help with this type of software testing, the general strategies and explanations he gives are definitely helpful in identifying meaningful test suites.

Rosenstock first describes Application Program Interface or API testing by defining the two main paradigms: Functional tests and Load tests.

Functional tests, aim to verify that the software functions perform as the specifications prescribes. Testing strategies such we learned in class such as equivalence class testing and boundary value testing can help us determine appropriate values to test in order to verify that the program behaves as expected.

Load tests on the other hand, test other real world complications that are out of the scope of functional testing. The main example Rosenstock goes into is the consistency and response time given an expected amount of user traffic. Load tests are generally functional tests that that are performed on many virtual users to simulate when the program performs in the real world.

From here on, the author describes the various types of load tests; what it is they are testing for and strategies for how to collect the information.

First, stress testing is the process of load testing where you start with a small number of virtual users and steadily increase the sample size and record specific performance times. This strategy gives information about performance at specific intervals.

Rosenstock also describes soak tests. The defining qualities of soak testing is to verify that memory efficiency is achieved. If there are any data leaks or unnecessary variables floating around in the software, and the maximum amount of memory is reached, the program can fail. So soak testing is the process of running load tests over a long period of time to determine that space efficiency is achieved.

I found this post helpful in illuminating even more situations that need to be tested for. While verifying the behavior specifications in a program is essential, there are also other real world situations that must be accounted for, such as the volume of user inputs. In this way, load testing is just as essential as functional testing, and this article definitely helped add to my understanding of the scope of good software testing.

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

From the blog Sam Bryan by and used with permission of the author. All other rights reserved by the author.

http://www.discoversdk.com/blog/unit-testing-with-junit

          This week, I found a blog post about Unit Testing, specifically, JUnit. The post began by explaining what Unit Testing is in programming terms and how Junit is a unit testing framework for Java and is tied into Test-Driven Development (TDD). The post explains the features of Junit focusing on how organized and simple it can be compared to other frameworks and testing methods. It specifically compares Junit testing to manual testing showing how tedious manual testing could be. It explains how annotations also work in Junit giving examples such as @Test and @Before while also explaining what they do. It uses real code to show simple tests being completed while also providing and explaining the outputs of each test. The post goes on to talk about the Junit rule which is a principle that works with Aspect Oriented Programming. It essentially means that Junit intercepts the testing method which allows the tester to manipulate things before and after certain test method executions. Junit can also provide a TestRule interface which allows the tester to create their own JUnit Rule for specification and customization.

      I chose this article because I found that I really loved learning about JUnit and wanted more information behind what it can do. I found that this blog post was important as a learning resource for me which made it more interesting to read. I was learning more about JUnit and its many other functionalities in testing which I previously did not know about. The post had a lot of information in it but used coding examples and definitions together to create a flow that read well and was understood much better. I enjoyed how it used these examples with comments and explanation within it to explain what was happening at each line of code. I was able to understand other uses of JUnit, specifically more about the annotations. I found that learning about the @Before and @After was very important to test methods and how they interact with the program while executing. The most interesting part of the post was the part where it explains how JUnit Rules work and how they can be customized using the TestRule interface. I found it very interesting that JUnit allows such customization for rules which makes it flexible as a framework. I thoroughly enjoyed reading this blog post as it did a great job introducing new concepts of JUnit in an understandable fashion while also refreshing the old concepts.

From the blog CS@Worcester – Student To Scholar by kumarcomputerscience and used with permission of the author. All other rights reserved by the author.

For my post this week, I found an excellent blog post by Martin Fowler on his personal website that details the “Test Pyramid.” The test pyramid is a way of representing the proportion of different tests you should be using for the purposes of keeping a balanced portfolio of tests.

As you can see by the pyramid, user-interface testing is slower and more expensive, moving to service testing which finds itself in the middle and then on towards unit testing which is speedier and less costly. This would imply that in general you want to rely more on unit testing than UI or service based testing, although all of these types of tests have a purpose.

Martin talks about the disadvantages of relying too heavily on user-interface testing. The slow testing increases build times and can require installed licenses for test automation software, which costs money and limits which machine the tests can be run on. The largest con Martin details was how brittle the tests were. That is, any small change to the system could break several tests and require them to be re-recorded. All these reasons show why the pyramid is the way it is, putting UI testing on the higher, smaller end. Fowler makes a point that often the usage of the high-level tests is as a second line of test defense. These tests are able to capture a bug you might have missed or not written tests for, and enables you to write a unit test to ensure the bug is taken care of.

I think the test pyramid is an interesting idea that highlights the importance of unit testing and helps define the priorities we should have as testers. Although it does not dismiss UI or service testing, it clearly demonstrates as testers that we should primarily be using unit testing to fix bugs in the code and make sure they stay fixed. High-level testing can be used to find things that are missed, but shouldn’t be relied on to catch bugs, and they won’t necessarily stay stable when you make changes to your program.

https://martinfowler.com/bliki/TestPyramid.html

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.

In this week’s blog post I decided to share an informative post by Henri Idrovo on dev.to detailing the implementation and usage of the factory design pattern, specifically the “Factory Method.” Henri starts the blog by introducing the problem the factory design pattern is aiming to solve: using the ‘new’ keyword creates dependencies on concrete classes within our program. When many new objects are being created, this tends to get out of hand. Henri introduced the dependency inversion principle, stating “Depend upon abstractions. Do not depend on concrete classes.”

To show how to implement and improve your code using the factory design pattern, an example is introduced that involves a Pizza Store that has to create different types of pizzas. Without the design pattern in place, every type of pizza you would want to make would require another if-statement, so clearly something needs to be fixed. In order to use the factory pattern, we need to separate what is likely to change from what is not, and put what will change in a class of their own.

In Henri’s example everything that is common to pizza creation is placed in an abstract creator class, and the specifics are placed in concrete creator classes that extend the abstract class. Similarly, the different kinds of Pizza are each given their own concrete product class that extends the abstract Pizza class.

The factory method seemed hard to understand at first, but after going through the examples given in the blog it became clear to me, and the advantages of using the factory method are clear. By relying on abstractions instead of concrete classes, you are removing dependencies within your code and making it much more open for modification. Whereas prior to applying the method, the handling of creation of pizza objects was handled within the PizzaStore class itself, it is now handled within concrete sub-classes that can also handle different categories of pizzas. Also, personally it is easier to read the code of the PizzaStore class after applying the factory method, and it is much more clean in the abstraction. I can see the factory method being useful in any situation where you have to deal with the creation of a lot of categorically related but different objects.

https://dev.to/henriguy/design-patterns-factory-pattern-part-1-6k0

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.

Today I will be talking about a blog called “Unit Testing, How to Write Testable Code and Why it Matters”. This blog talks about the importance of unit testing for anyone who is a software developer. The blog talks about what unit testing is, what it consists of, and something that I had never heard of until today; the three A’s of unit testing:  Arrange, Act, Assert. We will talk about these three A’s of unit testing in more detail later. Another thing the blog talks about is unit testing vs integration testing. The blog sums up the difference between the two as unit tests have a narrow scope to test just one small part of the program whereas integration tests test how the “pieces” of code fit together and work hand in hand. Essentially, integration testing is a larger scale version of unit testing. So what exactly makes a good unit test? According to the blog, good unit tests consist of tests that are easy to write, readable, reliable, fast, and truly unit testing (not integration testing). This is where the three A’s of unit testing come into play. After you make sure that your unit tests adhere to the rules of good  unit testing, you can apply the three A’s of unit testing. The three A’s (as mentioned before) are Arrange, Act, and Assert. Firstly, we arrange. We do this by testing small portions of the code (unit tests) to ensure they work as designed. Next we give the test some sort of input to “test” its function to make sure it works correctly, this is also known as the Act phase. Lastly, we Assert what we know our output should be and we then compare it to the output of the function we are testing.

I think this is an extremely important article because it has given me a lot of insight on how to make good unit tests and how to make the testing cycle easier by remembering the three A’s of unit testing; Arrange, Act, Assert. I hope to use the three A’s of unit testing in my future programs in hopes that my testing will go smoothly and quickly. Another thing the article talked about that cleared up some confusion for me is unit testing versus integration testing. For me, the two have always been kind of interchanged and intermingled, as they are very closely related. I think that many people know there is a difference between the two, but do not know exactly what that difference is. It is good to think of it as integration tests being larger scale unit tests. In my head, I now think of integration tests as being made up of smaller unit tests, and seeing how those unit tests work together. I think this article was overall a really good read and will make my approach to writing tests for my programs change for the better.

Here’s The Link: https://www.toptal.com/qa/how-to-write-testable-code-and-why-it-matters

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.