For the final blog entry for this class, I decided to cover a topic that I’ve had personal experience with but wanted to review for further review and understanding, mocking and specifically, mockito. I found an article on toptal.com by Ivan Pavlov about mockito that is a guide for everyday use of the tool, exactly what I was looking for! The article has sections that includes some in depth analysis that could likely be used as a more in depth documentation for several aspects of mockito. The article also includes some insight into what mocks and spies are in the context of testing, unit testing specifically as well as some examples of the mockito tool in action.

For unit tests, we are testing the smallest unit of code possible for validity. The article states that the dependencies are not actually needed because we can create empty implementations of an interface for specific scenarios known as stubs. A stub is another kind of test double, along with mocks and spies, which are the two test doubles relevant to mockito. According to the article “mocking for unit testing is when you create an object that implements the behavior of areal subsystem in controlled ways.” They basically serve as a replacement for a dependency in a unit test. Mockito is used to create mocks, where you can tell mockito what you want to do when a method is called on a mocked object.

A spy for unit testing is another test double used by mockito. A spy, unlike a mock, requires a non-mocked instance to “spy on”. The spy “delegates all method calls to the real object and records what method was called and with what parameters”. It works as you would expect a spy to, it spies on the instance.  In general, mocks are more useful than the spy as they require no real implementation of the dependency as the spy does. The spy is also an indicator that a class is doing too much, “thus violating the single responsibility principle” of clean code.

Mocking with mockito can be used in a situation where you want to test that an object is being assigned a specific value when a method is called on it and certain parameters are met. A mock does not require the implementation of the methods to be written yet as you can assign values when a method is called by the power of mockito. This is why mockito is such a popular testing tool and mocking is such a popular testing strategy, and why I’ll continue to utilize it whenever relevant.

Link to original article: https://www.toptal.com/java/a-guide-to-everyday-mockito

From the blog CS@Worcester – The Road to Software Engineering by Stephen Burke and used with permission of the author. All other rights reserved by the author.

For this week’s blog post, I wanted to cover a topic that we covered earlier this semester, boundary value testing. I found an article on seemingly my go to site for articles for this blog, guru99. The article has several sections including a brief definition on what boundary testing is, as well as a definition of what equivalent class partitioning is and the relationship between the two. There are also a couple of examples and an analysis section that explains why we should use equivalence and boundary testing.

The article describes boundary testing as “the process of testing between extreme ends of boundaries between partitions of the input values.” These extreme values include the lower and upper bounds, or the minimum and maximum acceptable values for a given variable. For boundary testing, you need more than just the minimum and maximum values though. For the actual testing, you need a value that is just above the minimum, a nominal value that lies somewhere in the middle of the range, and a value that is just below the maximum value.

Equivalent class partitioning is explained by the article as “a black box technique (code is not visible to tester) which can be applied to all levels of testing.” It also states that when using equivalent class partitioning, “you divide the set of test condition into a partition that can be considered the same”.  This may sound a bit confusing but it is actually pretty simple. The article uses an example of a ticket system where values 1-10 are the only acceptable values and values 11-99 are invalid. You could break up this set of numbers into two different equivalent class partitions and then returning back to our boundary testing concept, we would test values like 0, 1, 5, 9, and 10.

The best part about boundary testing is that because it is a form of black box testing, you do not need to see how the actual code works. You only need to know the specifications for the valid and invalid numbers. Another reason to use boundary testing is that it eliminates the need for testing every value and thus, minimizes the tests needed. I have and will continue to utilize this testing strategy throughout my software engineering career.

Link to original article: https://www.guru99.com/equivalence-partitioning-boundary-value-analysis.html

From the blog CS@Worcester – The Road to Software Engineering by Stephen Burke and used with permission of the author. All other rights reserved by the author.

For today’s blog post I wanted to cover mutation testing. I felt that this was a topic that we went over in class but felt like I may have missed something due to the short window of time that we had to review the topic. I found an article on guru99, a site that is becoming a go-to site for me, that is specifically about mutation testing. The article has several sections including a general overview of what mutation testing is, different types of mutation testing, and the advantages and disadvantages of mutation testing.

The article states that mutation testing “is a type of white box testing which is mainly used for unit testing.” White box testing implies that the code is inherently visible and known to the tester, or the person writing the mutation tests in this particular case.  The article states that the goal of mutation testing is to “assess the quality of the unit tests which should be robust enough to fail mutant code.” This opens up the conversation of what is this mutant code you speak of? The mutant code is a slight altercation to the original, and intended code such as changing a conditional > to a <. One of the most important aspects to note is that when performing mutation testing, only one altercation should exist for each test case. In the example I gave where you could change a > to a <, this would be the only change that would be made in the entire code that is being tested.

The article states that mutation testing is useful (the advantages) because “It is a powerful approach to attain high coverage of the source program,“ and it has the “capability to detect all the faults in the program.” Mutation testing finds any instances where a test should be failing but it is not. One of the biggest faults of mutation testing is that is nearly impossible to maintain without an automation tool, as stated in the article. The number of possible mutations to attain full coverage is not realistic to attain without automation.

I could see myself using mutation testing in the future as a means of attaining full coverage for testing. It is definitely a powerful means of testing if it can feasibly be implemented.

Link to original article: https://www.guru99.com/mutation-testing.html

From the blog CS@Worcester – The Road to Software Engineering by Stephen Burke and used with permission of the author. All other rights reserved by the author.

For this particular post, I was in the mood to cover something that we haven’t specifically covered in the class, stress testing. I found a post on guru99.com that covers stress testing as a whole. The article covers aspects including the need for stress testing, as well as different types of implementations of stress testing. I particularly enjoyed this post because it covers a broad realm of topics within this particular area of testing, while being easily understandable for someone who may have no familiarity with the concept whatsoever.

Stress testing is often associated with websites, and mobile applications that may experience abnormal traffic surges during some predictable times and sometimes completely unpredictable times. Stress testing ensures that a system works properly under intense traffic, as well as displays possible warning messages to alert the appropriate people that the system is under stress. The post points out that the main end goal of stress testing is to ensure that the system recovers properly after failure.

A few different means of stress testing are, application stress testing, systemic stress testing, and exploratory stress testing. Application stress testing is pretty self explanatory, this test basically looks to find any bottlenecks in the application that may be vulnerable under stress. Systemic stress testing tests multiple systems on the same server to find bottlenecks of data blocking between applications. Exploratory stress testing tests for some possible edge cases that are probably unlikely to ever occur, but should still be tested for. The post gives examples of a large number of users logging in at the same time and when a particularly large amount of data is inserted into the database at once.

I knew that this kind of testing had to exist because of my experience with certain applications. Years ago, when a new Call of Duty game would come out, it was often unplayable for the first day or two, due to the network system being completely offline or simply unstable. Now, presumingly they have figured out their stress testing as the service does not go offline on release and hasn’t for several years. Personally, I don’t know if I will particularly be involved with stress testing in my career but the exposure to this area of testing cannot hurt. I do recommend that people take a look at this post on guru99.

Here is a link to the original post: https://www.guru99.com/stress-testing-tutorial.html

From the blog CS@Worcester – The Road to Software Engineering by Stephen Burke and used with permission of the author. All other rights reserved by the author.

For this week’s blog post, I decided to find a blog post on a topic that we haven’t explicitly covered in class. I found an article on Agile Testing and my interest in Agile as a whole drew me in. This article is on QASymphony and breaks down what Agile methodology is, some examples of Agile testing, and how to align testing with the Agile delivery process. For the sake of this post, I will assume you’re familiar with the general concept of the Agile methodology for software development, hopefully you understand the general concept of Scrum and Kanban.

One of the interesting testing strategies for Agile development is the Behavior Driven Development tests (BDD). These tests are similar to the Test Driven Development (TDD) style testing systems in traditional waterfall development cycles. They are basically a replacement. Instead of writing unit tests before code is written, the BDD tests are on a much higher level. This is how user stories are written. The development of the code is based on end-user behavior and the tests need to be readable for those who might not be particularly technical as they can often replace requirement documentation. This saves time in the long run as there is no duplication of the process for those who might not be able to read user tests in the traditional TDD style of testing. The best part about BDD testing is that the tests do not necessarily need to be written by technical team members. These can, and are often written with input from business partners, scrum masters, and product owners who might not necessarily be able to contribute when it comes to writing unit tests in the TDD format. This style also allows for testing small snippets of functionality like TDD so that one aspect of TDD that is somewhat Agile remains intact for BDD testing.

After reading through the other testing strategies and how to align testing with the Agile methodology, I realized that I’ve already been working in systems that operate like this at my summer internships. We operated our testing in a format pretty much identical to the concept of BDD where everyone in the team contributed to the different testing obstacles and even came up with test cases that would need to pass by code that was written afterwards. And like the article says, it was common for not all of the tests to pass immediately, and this is part of the concept of “failing fast” that Agile is all about. I am glad I found this article to give me more insight to how businesses around the world, including the ones I interned at, are converting to Agile and utilizing these testing strategies if they haven’t already.

Link to original article: https://www.qasymphony.com/blog/agile-methodology-guide-agile-testing/

From the blog CS@Worcester – The Road to Software Engineering by Stephen Burke and used with permission of the author. All other rights reserved by the author.

For this week’s blog post, I decided to choose a subject that would give me a little more experience with a technique for black box testing, or developing tests for software without direct access for the code for a particular application. This way, the tests are created with a bigger focus on the business logic instead of particular barriers that may arise within a programming language or the overall stack of the application. I found an article on softwaretestingclass.com that covers the usefulness of decision tables in regards to software testing. The article discusses how to use decision tables as well as why they are such an important tool for black box testing. The article also mentions other examples of testing techniques for black box testing.

The author, Venktesh Somapalli, provides an example of a financial application where there are two possible conditions for a user, repayment within a term, or moving on to the next term of a loan. Somapalli goes through the steps that a tester may consider constructing a decision table for this particular application. The table for the decision table technique is based on conditions either being true or false, so all outcomes are absolute. This means that there are there should only be one outcome for a set of conditions. However, the reverse of this is not true, there are can be more than one set of conditions that have a particular outcome. In the example in the article, if both of the conditions are true or false, an error message is the outcome. On the other hand, there is only one set of conditions that processes money, and one that processes the loan term.

My favorite part of this testing technique is that it is inherently non technical due to the nature of black box testing and the simplicity of the concept. This means that non technical people within a business can understand and even develop test cases using this technique. As Somapalli points out, this technique is also versatile because it can be applied to any set of business logic. Somapalli also notes that decision tables are iterative meaning that if any new conditions are added to the logic, the existing table can be reused and revised to consider the new logic without a complete reconstruction. I definitely agree with his arguments for the usefulness for this technique. I have used this technique in the past and before reading this article, I didn’t even consider the powerful nature of this versatile strategy. I will definitely continue to make use of this technique when developing test cases whenever possible throughout my career.

Link to the original article: https://www.softwaretestingclass.com/what-is-decision-table-in-software-testing-with-example/

From the blog CS@Worcester – The Road to Software Engineering by Stephen Burke and used with permission of the author. All other rights reserved by the author.

For today’s blog post, I wanted to cover a specific topic that I don’t particularly enjoy. While that may sound counterintuitive, I feel that it is important to repeatedly work on skills, even if they aren’t your favorite to practice. So for today’s post, I found an article on imalittletester.com about using try/catch blocks in testing. I don’t particularly enjoy try/catch blocks even though they are incredibly useful and necessary. The author explains multiple scenarios that may occur with try/catch blocks, ensuring that false positives are avoided. She dives into the scenarios, using pseudocode to illustrate what a method may look like for each scenario, and examines how tests must be constructed for each scenario to test the proper criteria.

One of her examples, the scenario where a test should only pass if an exception is not thrown is probably my favorite. She explains that the try/catch block isn’t really needed in this scenario because if we are testing that an exception is not thrown, code without a try/catch block would fail just the same as the try/catch block. This is one less scenario that I’ll have to use the dreaded try/catch blocks.

In my opinion, the most confusing of the four scenarios is how to write a try/catch block where a test should only pass if the exception is thrown. The author explains that what must be done to ensure your test works properly is to have a marker in the try block that will execute if and only if the code that is supposed to throw the exception, doesn’t throw the exception. When executing this try/catch block, the only time that this marker will execute, is when your test is failing. The author explains this in a way that is clear, and easy to follow even for those of us who have such a dislike for try/catch blocks.

In all honesty, I’m glad that I chose this article. I try (no pun intended) to avoid using try/catch blocks as much as a I can, as they can be confusing to me at times. But like I said in the beginning of this post, it is extremely important to practice skills and possibly even more important to practice skills that you don’t particularly like. I will definitely consider this article the next time I’m forced to incorporate try/catch blocks in a program I am writing.

Link to the original article: https://imalittletester.com/2017/04/24/better-test-code-principles-5-mind-your-trycatches/

From the blog CS@Worcester – The Road to Software Engineering by Stephen Burke and used with permission of the author. All other rights reserved by the author.

This article by Ekaterina Novoseltseva on DZone (DevOps Zone) is about 8 benefits of unit testing. In the article, she breaks down how her company, Apiumhub, utilizes unit testing in order to stay Agile. She also breaks down several of the benefits of unit testing including relation to Agile, quality of code improvements, reduction of costs, and several others.

I found this article interesting because while I knew some of these benefits of unit testing, I never thought of some of the specific examples like the relation to Agile. She points out that unit testing facilitates “safe refactoring” by forcing developers to use the smallest functionality possible for testing a single unit. I agree completely with her in regards to Agile especially after she pointed out that this goes hand in hand with extreme programming and test driven development.

Personally, I’d never used test driven development at a large scale before so I’ve never really considered the benefits. The section on the benefits to design really pushes the idea that test driven development makes code more optimized, with cleaner designs. When breaking everything down into a unit first, figuring out what each unit is, and defining what the functionality is through tests, you are forced to consider the designs of the actual functions before writing them.

Another point that she makes that is probably one of the most important to the business is that unit testing reduces costs for the development process. Unit testing finds bugs early in the process because the tests are either written before the code is even written, or before moving onto the next snippet of functionality in order to stay Agile. This means that application-breaking bugs are less likely to be found in the later stages of the development process like “system testing” or “acceptance testing” as Ekaterina points out in the article.

I wholeheartedly recommend this article to anyone who is relatively new to unit testing and doesn’t is any bit unsure of the possible reasons why unit testing is so important. I can see myself utilizing unit testing more in my personal projects in the future as I already try to work on them in some resemblance of an Agile process.

From the blog CS@Worcester – The Road to Software Engineering by Stephen Burke and used with permission of the author. All other rights reserved by the author.