For today’s blog I will be discussing the topic of testing with mocking. I recently read an article called “Mock? What, When, How?” by Lovis Moller. So let’s jump right in. What is mocking in terms of testing? Think about your code as a giant puzzle. All the pieces fit together, but they fit together in specific ways. Say you’re missing a piece of the puzzle because your partner hasn’t finished their part of the code yet. The new problem is this: how can I test my code without my partner’s piece of the puzzle? The answer is by using mocking. Mocking allows us to emulate or “mock” our partner’s puzzle piece that we are missing so that we can test our code without having to actually have the rest of the puzzle pieces. So mocking seems like a pretty good idea and like something we should use all the time, right? Wrong. The article talks about some of the pitfalls of mocking, which we will now talk about. First, the article says to mock only code you own. Do not mock third-party code simply because it’s not yours and you do not know how it works or how it should work. Another rule of thumb is to avoid mocking values and concrete classes. You should avoid mocking values because the objective of mocking is not to test for specific values, but rather it is meant to test the relationships and interactions between different classes (pieces of the puzzle). Concrete classes should not be mocked because of all the extras (methods, unused lines of code, etc) that come along with the  concrete class. It is more efficient to use mocking with an interface in this case.

In the past few weeks we have been doing testing with mocking in our CS class. I think it is a really neat and useful way to test because you can get stuff done on your end without having to wait for someone else to finish. In a world where we work as groups to complete projects, human error is always an issue. We could have our parts of the code done weeks before a deadline while our partner waits until the night before the deadline. Problem here is that we might not be able to proceed in testing and fixing our code because what our code does as a function relies on our partners code. We certainly do not want to wait until the night before a deadline to test and fix everything. Mocking helps us with this by emulating the code we are dependent on. I hope to use this more in the future.

Here’s the link to the blog: https://blog.codecentric.de/en/2018/03/mock-what-when-how/

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.

This article from softwaretestingmagezine.com talks about how testing and monitoring live and active services is a key element of software quality assurance. After deployment, making sure all of the bells and whistles of a service are up-to-date is a very important thing. Not only is it important on the programmer’s end, but it is extremely important on the client side because you should have a smooth experience for the both of you. Without proper testing of a product or service, it is impossible to correctly gauge how it will perform, which is why pre-launch and post-launch immanence testing is a must, especially today. This article then goes into many online services that monitor performance and uptime of certain services. Let’s go into some of these now.

A very important aspect to tracking a service is by recording it’s uptime. A service called “StatusCake” does just this. StatusCake is a paid monitoring service that can monitor page speeds had extremely high rates. They claim to have a very large system for monitoring big servers. Another nice thing about StatusCake is that it can set reminders about domain renewals. SSL monitoring, and much more. Although at may seem like monitoring uptime of your service wouldn’t make sense, it is actually very crucial in many ways. One thing I learned from this article about how important this is, is by monitoring your up time, depending on how long a service is kept online without failing, you can determine by logging where issues lay when something does occur. Something such a service outage or service lag can easily be tracked and tested if you have tools available to help you track it.

Tracking these issues with a system can be tricky, but there is another testing tool that can help us do exactly this. This tool is called Uptrends. Uptrends is another software testing tool that actually notifies you and double checks when something is wrong with your service. One of the harder things is tracking exactly when or where an error in a service occurs. The interesting thing about Uptrends is that it will actually give you detailed reports and statistics on these errors and also sends out email alerts when something goes wrong. This is another very important aspect of software quality assurance and testing. When something goes wrong you need to have information about the failure as fast as possible. With services such as this, you can receive notifications as soon as the fault happens so you can act accordingly to the issue.

Many services are available to help developers and clients for software testing and quality assurance. Depending on what you need, it is very important to keep a close eye on operations after a service is launched or completed, especially if it is being upgraded or modified in any way.

From the blog CS@Worcester – Amir Adelinia's Computer Science Blog by aadelinia1 and used with permission of the author. All other rights reserved by the author.

https://www.qualitylogic.com/2018/01/11/closer-look-integration-testing/

Integration testing is the process of assembling various code modules to preform very specific tasks in a software system that uses them in a more generalized application. The article gives the example of using a module that stores and retreives files with another that displays their names in a list and another that reads keystrokes as well as one that that recognizes mouse clicks, all together it is a file manaement application. Each module is usually created and tested seperately using unit tests before being added to the code control system. After in the management system they are subjected to integration tests which tests them in conjunction with other modules. This usually uncovers issues with data formats, operation timing, API calls, database access and user interface operation.

There are four parts of integration testing that are critical. The first one is software integration which means in part that everything fuctions the way the user commands. For example, with interface operations it is important that when a user does something unexpected by the systems design the application does not simply crash but produces an error message. Next, the modules must continually exchange data as the overall system functions. This is often performed by a data or command bus that facilitates module communication. These buses are often the most stressed component of the system and integration tests should test them under various amounts of load to ensure that the individual modules are working together properly. Third are the API calls which are the most common channel by which the system communicates with third party services and has become a tool for connecting modules together within the system. This allows data and commands to be separated into different function calls making the exchange easier to debug. One of the main issues with API calls for integration testing is that each one needs to be tested separately, through the entire set of data and inside and outside the acceptable range. Then API calls must be tested in functional groups. Finally there is End-To-End testing which is a big priority for integration testing. The test sets up a system called a sandbox environment and then creates tests for every use the application would go through in real world use. User inputs simulate the front end with data and requests which are then communicated to the middleware to work with the backend of API calls to third parties and database manipulations. All of this is carefully monitored for accuracy and run time.

From the blog CS-443 – Timothy Montague Blog by Timothy Montague and used with permission of the author. All other rights reserved by the author.

I think it is extremely cool that with a simple tag at the beginning of an individual Junit test, the entire execution of the entire collection of unit tests in a given source file. When reading about tags such as @BeforeEach and @BeforeAll after going over it briefly in class, I came across an article which describes the most common tags used for Junit tests, found here: https://www.testingexcellence.com/junit-5-annotations/.

Some of these tags are repeats from what we have discussed in lectures, but I find it helpful to rephrase the functions of each tag so that I better understand what each of them does.

@Test – This is a broad tag which simply denotes the presence of a Junit test method to be executed. There are no parameters for this tag.

@ParameterizedTest – This tag specifies that the test being executed must be run multiple times, but with different arguments each time. The test method is defined in the same way it would be under a @Test tag. However, along with the switch to a @ParameterizedTest tag at the beginning of the method, the tag @ValueSource is also used below this initial header. The attributes for this ValueSource tag denote the different arguments to be used and consumed by the test method.

@RepeatedTest – This tag describes a test method being executed a given number of times, specified in the attribute field of the tag. The difference between this tag and the @ParameterizedTest tag is that the same arguments are used for the @RepeatedTest.

@DisplayName – This tag allows the given test method to have a custom display name, which is shown by test reports and during runs. The name (as a string) is the single argument of the tag.

The next few tags affect the order that test methods are executed. Each of them are pretty self-explanatory.

@BeforeEach – With this tag, the specified method will be executed before each of the other test methods.

@AfterEach – Likewise, the method with this tag will be executed after each of the other test methods.

@BeforeAll – This tag denotes a test method being executed first in the order of all of the test methods.

@AfterAll – This tag denotes a method being executed last in the order of all of the test methods.

@Tag – This tag allows filtering or grouping of test methods by adding a custom tag name for its argument.

@Disabled – This tag causes its test method to be skipped.

While there are certainly more annotations in these Junit tests, I’m glad to learn the common tags for further testing in my Software Testing course.

From the blog CS@Worcester – Hi, I'm Kat. by Kat Law and used with permission of the author. All other rights reserved by the author.