A Valuable Lesson for Creating Tests

Article link: https://dzone.com/articles/why-you-should-stop-now-testing-every-class

A great article I read today goes over the importance of creating the correct kinds of tests for software. In this article, the author thoroughly explains the importance of testing the “behavior” of software versus “implementation details” and how not “every single class” needs to be tested. I think the author does a great job with both an easy to understand narrative and tons of example code that illustrate the importance of testing that software performs to specification versus testing how the code is written. The example code given in the article goes further with linking to an entire GitHub repository for the example code (which elaborates beyond what is shown in the article) which I really appreciate as it lets me see exactly how this concept aligns with a complete program. The most interesting part of this article for me was in the author’s explanation of how refactoring code can cause tests that are written (incorrectly) to a specific implementation to fail. I think it is important to see this point that putting in extra effort in developing software but on the wrong things can actually do more harm than good further down the line. Especially as the author points out if you were to further refactor the code and change how it works (even return types as the author demonstrates!), this causes bad tests to fail, which only creates even more work. I never really thought of how refactoring could create more work in a testing scenario before reading this, but I like how refactoring further helps the overall program by exposing the appearance of useless tests. One other part of the article I really enjoyed was the side narrative the author gave while working through his example of how the steps they took followed TDD (test-driven development). This is also something I wanted to learn more about, and this article also provides a good example of TDD by explaining how certain practices taken in the code example adhere to the rules of this methodology.

Overall, I think this article covered an important topic well, and serves as a great reminder at the end of our testing course to make sure we are testing the right things in our software and that we are not creating too many, and useless tests that only hinder our efforts and not help us. I will certainly keep this article in mind when writing future tests to ensure I’m not wasting my time by creating the wrong kinds of tests or making sure every line is tested in a program.

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

Mutation Testing

Last Thursday in CS-443, I was introduced to Mutation Testing. This is a testing method which uses tools to embed faults into a project’s code before running its tests. The idea behind it is that, if the tests are written well, then they should fail when mutations are introduced. The in-class activity introduced Mutation Testing by having us clone a Java project and running the PIT tool to test the project with mutations. While the activity effectively demonstrated how to use PIT, I felt that it did not give me a complete understanding of Mutation Testing in general. This was mainly due to some confusion I had while trying to figure out how to run PIT. For this reason, I decided to research Mutation Testing on my own to help improve my understanding of it. I eventually came across an article from softwaretestinghelp.com that I think provides a great introduction to Mutation Testing.

Link to the Article:

Mutation Testing: Testing Technique with a Simple Example

The article demonstrates Mutation Testing with an extremely simple pseudocode example consisting of a single if statement. The example has five different types of mutations applied to it (called ‘Mutation Operators’) which demonstrate how adding mutations can alter the results of tests. Some of these mutation operators, like relational and arithmetic operator replacement, were demonstrated by the class activity. Others, like statement removal and absolute value insertion, were completely new to me. This taught me that there is a much wider variety of mutation operators than the activity demonstrated.

I also found that the article made it easier to understand how the mutations affected the results of the tests. In this article, the results of the Mutation Test are listed in a table with each column representing a different mutation made to the example code. This makes it possible to see exactly which test values either kill the mutants or cause them to survive. It also makes it easier to notice syntactically incorrect, equivalent, and trivial mutants, which the article mentions should be avoided. I disliked how the Mutation Test results were reported by PIT as a generic list of mutations with vague information describing why they survived or were killed. Having the results in the article be presented in a table and being able to refer back to the actual mutated code made it much easier to understand the results of the Mutation Tests. Compared to the in-class activity on PIT, this article uses a much simpler example to demonstrate mutations and presents the results of its Mutation Tests in a much clearer way. This has helped me better understand the fundamentals of Mutation Testing, and I think I will be able to use tools like PIT more effectively as a result.

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

Final Project pt.3

After starting work on our front end code we needed to create a method to allow users to search our database for a specific ‘artist’ name or by all artists that contain a specific letter or String entered by the user. For example, if the user input the letter “A” then they would be presented with a list of all artists whose names start with “A”. In order to create this function we needed to start with the backend.

In our Java rest api we needed a get method to search our database. The query in SQLite would be “select * from artists where name like ..%”. The “..%” is where the name of the artist we are searching for would go, but since we want the query to be unique to user input the “%” basically acts as a “don’t care”. This allows for whatever the string is that the rest of it doesn’t need to be specified and all artists will be returned that contain that string. To allow our users to input the string to be searched for we setup the query slightly differently in our backend. We use the query “select * from artists where name like ?”. The question mark acts as an operator to take user input. Then we use the statement:

statement.setString(1, name + ‘%’);

This statement sets the string we’re searching for to the first (and only) input from the user and then adds “%” after the string. Here’s a look at our full method: 

@GetMapping(“/artists/{name}”)

public ResponseEntity<Object> getArtistByName(@PathVariable String name) throws SQLException {

   PreparedStatement statement = 

conn.prepareStatement(“select * from artists where name like ?”);

   statement.setString(1, name + ‘%’);

   ResultSet rs = statement.executeQuery();

   ArrayList<Map<String, String>> results = new ArrayList<>();

   while (rs.next()) {

       Map<String, String> temp = new HashMap<>();

       temp.put(“ArtistId”, rs.getString(“ArtistId”));

       temp.put(“Name”, rs.getString(“Name”));

       results.add(temp);

   }

   return new ResponseEntity<>(results, HttpStatus.OK);

}

Then in our front end Typescript code we connect to the rest api backend with this method:

getArtistsByName(str: string): void {

 this.error = null;

 let tempStr = str.replace(” “, “%20”);

 this.http.get<Artists>(‘http://localhost:8080/artists/&#8217; + str)

   .subscribe(response => {

       this.searchArtist = response;

       console.log(response);

     },

     (error: HttpErrorResponse) => {

       this.error = error;

     }

   );

}

This method allows us to get all the results to the front end so that we can then print the results on our web page for the user to see. We continue to do this by implementing our html code to display these results in drop down lists for the user.

The idea of our project developed into a web page that allows users to search through a database of music artists and their albums and allow the user to select an album that they wish to download. They cannot truly download music from out web page but this is a framework for the idea of a web page with that purpose.

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.

Mockito

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&#039;s Blog by zloureiro and used with permission of the author. All other rights reserved by the author.

Progress and Pain

I have not been able to dedicate as much time as I would like to this angular web app project, and I have a lot to learn. I was also not able to incorporate the google sheets api to do the things I really wanted to do. However, what I have done I’ve found engaging and interesting.

I made the decision to simulate a data server in angular. This made data manipulation fairly easy. It took the stress off of figuring out the back-end and allowed me to focus on the other aspects of angular: the structure, services / components, and HTML / CSS. Utilizing several tutorials and guides, I am fairly confident now in creating buttons and forms that accept user input and pass that input into a list. The list is clickable and displays details. It also routes to another page complete with its own URL.

I learned a lot about ngif and ngfor, which work in a pretty familiar fashion. I also learned about the “Slice” function, where you can iterate through a specific part of an array. I am hoping to add a function that will display my win / loss record, which can be done by just adding the values in the “Win” portion of the data, as it is represented by a 1. This is a work in progress but I think it will be doable.

I still think Tour of Heroes should be included in this class. It was such an eye-opening tutorial, and really let me dig deep into learning about services, components, routing, HTML, CSS, and more. While it’s a long tutorial, I think it would be better than Activity 12 for a teaching tool.

From the blog CS@Worcester – Alan Birdgulch&#039;s Blog by cjsteinbrecher and used with permission of the author. All other rights reserved by the author.

Static testing and Dynamic testing

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&#039;sCSBlog by and used with permission of the author. All other rights reserved by the author.

Black Box, White Box and Grey Box testing

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&#039;sCSBlog by and used with permission of the author. All other rights reserved by the author.

Mutation Testing

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.

Final Project

My final project has not been an easy task to deal with thus far. After going far in depth with one of my designs, I came to discover that the use of angular material alongside bootstrap which caused quite a few problems. I have decided to do a full overhaul into angular material. The reason I am choosing angular material is because there seems to be more typescript capabilities while bootstrap seems to be heavy on javascript and css. By going down this path I have been able to make steady progress with my current version of my application which at the time is mostly an interactive sidebar. The main concern I will have this week is being able to make the workouts appear on the home page. I would like to be able to use angular to create a visually appealing layout which will allow for the user to go through the different workouts and select the ones that they would like to use. If I was able to have more time on something like this my end goal would be to add in I/O devices such as being able to print your workout after it has been created. Due to time restraints I will have to remain with simply being able to select and track the wanted workouts on the app. Another large problem I will have to come up with a solution with is whether or not there will be a way to save workouts, or have the workouts appear and when the next desired workout regime is needed, to simply delete the old and then add to the new one. Another issue I have run into is being able to seamlessly add in new workouts to the app without having any effect on the previously existing workouts. This next week will be the time to grind out any and hopefully all of these problems. I have been diving deeper into angular material in order to get a better understanding. I have also been researching more html and css as I have not had much prior experience with these. This has caused me quite a bit of stress because very minute changes have broken the entire app, but I believe that by completing this I will have gained the necessary knowledge of what will be needed in the future. I am excited to complete this app but it is also been an extremely difficult time which will all pay off in the end.

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

CS-343 Final Project – Part 3

Over the past week, my work on my CS-343 Final Project has been focused on creating a more interesting layout for my components. I have not changed the function of the program or added any more features yet, but I think I have made some great progress towards making the GUI look more like I planned it to in my wireframe. The program currently looks like this:

I managed to create this layout by making use of Angular’s Grid List material. Using material.angular.io as a reference, I was able to figure out how to import this tool into my project and use it to arrange components with the <mat-grid-list> and <mat-grid-tile> tags in my app.component.html file. By combining this information with what I learned about CSS and HTML last week, I was able to create the layout pictured above.

In addition to working on the layout, I made some major changes to the project’s organization. One significant change was the creation of a new Angular component: the options-menu. Previously, the input forms for changing width and height were simply parts of the app.component.html file. I decided it would make more sense to create a new component so that these options and the new options I plan to add this week will stay organized in my new layout. Another major change I made was in the way data is passed between components. Before, I simply had the input forms in the app component update the size of the rectangle by searching for it by its id. Now, the forms actually pass data from the options-menu to the rectangle using a data service. I decided to implement this method of data sharing after reading about it in this article on angularfirebase.com (see the section on Unrelated Components). I had difficulty understanding how a data service works at first, but I eventually understood it by messing with my own. Creating a data service has definitely made passing data between components far simpler than it was before, and I plan to add more to it this week.

As I am due to present my completed project this Friday, I have less than a week to finish working on it. My plan for this week is to finish adding the features I planned for the project in the beginning. This includes making a simple puzzle game that can be played in the rectangle area, as well as more options to configure it besides the width and height. I would also like to work on cleaning up my layout to make it more visually appealing. Finally, if I have time, I would like to create a back-end server that will allow users to store their scores form playing the game. It seems like a lot to add, but making this layout and creating a data service have only made me more comfortable working with the Angular framework. I think I will be able to complete much of what I have planned in time for Friday.

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