Mockito is a framework in Java that creates Test Doubles for users that can be used with Junit. Test Doubles as described in my last blog are basically simplified tests for your code that more or less test setup over functionality. They are used to help you make sure you are setting up your code correctly in the early stages before it gets overly complicated. It’s good practice to test at this early stage in the process because simple setup and organization errors can become an overwhelming problem further down the line if you don’t find them early on. Mockito is a great framework to help you quickly generate these Test Doubles. Mockito creates mock objects with dummy values to make sure tests pass, as long as your setup is correct.

Check out this code example:

package com.journaldev.mockito;

import static org.junit.jupiter.api.Assertions.assertEquals;

import static org.mockito.Mockito.when;

import org.junit.jupiter.api.Test;

import org.mockito.Mockito;

import com.journaldev.AddService;

import com.journaldev.CalcService;

public class CalcService1Test {

@Test

void testCalc() {

System.out.println(“**— Test testCalc executed —**”);

AddService addService;

CalcService calcService;

addService = Mockito.mock(AddService.class);

calcService = new CalcService(addService);

int num1 = 11;

int num2 = 12;

int expected = 23;

when(addService.add(num1, num2)).thenReturn(expected);

int actual = calcService.calc(num1, num2);

assertEquals(expected, actual);

}

}

This code uses a mock() method.

To continue reading about this example check out this website:
https://www.journaldev.com/21816/mockito-tutorial

From the blog cs@worcester – Zac's Blog by zloureiro and used with permission of the author. All other rights reserved by the author.

Static testing and Dynamic testing is two different approaches to testing available for developers and testers in the software development process. In order to get the most out of these tests, this has to be chosen carefully and it is important to understand the benefits and the limitations of each one.

Static testing is a test method where code are not being executed and it can be done manually or using a set of tools. This type of testing would check the syntax, required documentation and design of the code. Static testing also includes security testing to analyze the software for potential errors, code flaws, or vulnerabilities. This method can be start in the early development stage of the program, and it can be done on work documents like specification documents, design documents, web page contents, etc. Static testing techniques include:
–  Inspection: The main purpose of this is to find defections. This task can be reviewing the check lists, work documents, or code walkthroughs and it is conducted by moderators.
– Walkthroughs: This technique would require the author to conduct a meeting to explain the product. Participant can ask questions and a scribe is assign to make notes.
– Technical review: This technique is to check if the written code is matched with technical specifications and standards. Test plans and strategy is reviewed here.
– Informal review: Documents in this technique should be reviewed informally and comments should be added.

Dynamic testing is done when code is in execution in a runtime environment. When code is running, the predefined input should get the expected result for the test to return positive. With this, developers can observe features of the program and monitoring the effect of this program on the running hardware. There are two types of Dynamic testing: functional and non-functional testing. Dynamic testing techniques include:
– Unit testing: testing individual modules by developers.
– Integration testing: testing the performance when different modules run with each other.
– System testing: testing the system as a whole.
– Acceptance testing: testing from user’s perspective end.

Article can be found here.

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

Black Box, White Box and Grey Box are there most common terms in testing as it is really important. These terms are selections of tests that developers have that is based on their purpose of testing, what is being tested, and they determine which what tools or technologies to be used in order to tackle to problem efficiently.

Firstly, let’s talk about Black box testing. This type of test is really common on testing user interface. It treats the program as if it is a “black box”, or refer to testing without knowing or be able to change the internal implementation. It is also known among developers as closed or opaque box. The advantage of this type of testing is pretty huge, as developers can focus more on how to test the feature, rather than having to get to know the internal code. It also needs low time to prepare, and designed to simulate the perspective of users. With those potential advantages, the trade off of Black Box testing is also huge, as it might have a chance to have redundancy in tests, and QA engineer has to blindly explore the system without knowing the source of error, if the program has some.

White Box testing is basically opposite to Black Box testing, which allows the QA engineer to fully access to internal data structures and implementation. They are not only able to view the source code, they can also manipulate the code as part of the testing process. This is also known as clear box or open box testing. The advantages could bring a lot of benefits to developers as codes can be tested during the development process of a feature, which allows them to spot out bugs almost immediately. With the ability to access to the internal, QA engineer can use test in order to test for performance and optimization, and also it is a good practice to have code reviewed by multiple developers. The disadvantages can also be huge in contrast to what are mentioned before. White Box testing would require very in depth knowledge about the system and the duration of these test should correspond to the length of the source code, which is a lot. This type of test can also have a big influence from tools from development process that can affects the test cases and it is not scalable in anyway.

And finally, Grey Box testing, which is a combination of Black Box testing, and White Box testing. It allows the QA engineer to see the internal implementation, but cannot modify them directly. The advantages and disadvantages from this, is pretty much also combine between the two previous type of test. Grey Box testing can have the program to be seen as the level of user, while also can use the internal implementation to optimize the test cases. The downside of this is that QA engineer will not be able to change the source code, and have to play around with it multiple times to find a correct way to tackle the problem.

Article can be found here.

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

PIT mutation testing is great way to test code that may seem like it passes everything, but still contains errors. Mutation testing will insert these faults into your code and will then retest the code to make sure they are properly handled. If a mutated test is killed, that means it was properly accounted for by the test cases and code. If a mutation survives that means that somewhere in the code, there is an error that is not being handled properly. An example of mutation testing will be something along the lines of taking a less than sign ( < ) and making it into a less than or equals ( <= ) to see if the code will be able to kill this mutation or if it survives then something must be fixed.

From the blog CS@Worcester – Journey Through Technology by krothermich and used with permission of the author. All other rights reserved by the author.

Time to read up on mutation testing. Jasper Sprengers’ article, “Sensible mutation testing: don’t go on a killing spree,” gives a small overview of mutation testing and then explains how killing all mutants is not always necessary. The article uses an example to show how a simple class requires extensive testing to kill all mutants. The example shows how a small class of around 10 lines and a single method requires 18 test assertions to kill all mutants. This shows that it is important to consider letting some mutants live. It is not always efficient to use the extra time expanding the tests. My takeaway from this article is that mutation testing should be used to find situations where your tests are not thorough enough but not all mutants are worth the time killing. Use mutation testing with discretion.

Article referenced:
https://blog.codecentric.de/en/2016/02/sensible-mutation-testing-dont-go-killing-spree-2/

From the blog CS@Worcester – D’s Comp Sci Blog by dlivengood and used with permission of the author. All other rights reserved by the author.

Test Doubles is a term used to describe code tests that are basically imposters of themselves. They are unfinished and simplified versions of what the actual tests would be. Thus, they are doubles of their true forms. Theses doubles are written in order to satisfy and verify that you code is functioning and is setup at the most basic level. Test Doubles contain three different types; Stubs, Mocks, and Fakes. Each of these types is used in a different way to help get your testing going but without getting too complicated. 

A fake test allows us to take a shortcut when testing functionality. Say you have a database that your code connects to. Instead of starting up and running a connection you could have hard coded values in your code that you retrieve for your tests. So in this way you aren’t really testing the right values but that your code is able to get values at all.

A stub has a similar idea with using hard coded values to satisfy your tests. Essentially all you do is create a test, then make sure that the code that is being tested has exactly the results that are expected. For example, if you’re testing if a rectangle object is a square then you don’t actually create the rectangle, instead you return the expected value to the test class.

A mock is used when we just want to verify that our code is being called or accessed correctly without actually functioning the way we are intending. If you have a method you want to make sure is called correctly you can have that method be empty but when it is called it prints a string “Method … accessed correctly”. This way you know that you are calling the right method without having to actually test its functionality yet.

Here is a link that helps explain these Test Doubles:

https://blog.pragmatists.com/test-doubles-fakes-mocks-and-stubs-1a7491dfa3da

From the blog cs@worcester – Zac&#039;s Blog by zloureiro and used with permission of the author. All other rights reserved by the author.