Test Automation

Article link: https://dzone.com/articles/starting-automation-testing-from-scratch-here-is-w

Throughout this semester we have learned about how to create tests in a mostly “manual” way, today I want to explore an article that serves as an introduction and overall guide to automation testing. I especially wanted to learn about this topic since it has repeatedly come up in other articles I’ve read on this website.

Overall, I found the content of this article to be great and I think it thoroughly covers every aspect I can think of, and acts as a great beginner’s guide to this topic of automation testing. The author methodically covers everything on automation testing from the benefits of switching, to figuring out which areas of your testing should be automated.

Looking at the section of this article that lists the different areas automation testing can help is particularly interesting to me as most of the types of testing here I am unfamiliar with (and aren’t covered by our testing course) but would like to know more about. This includes areas such as regression testing, which I just learned about, and performance testing. From this article it seems that automation testing seems to help particularly with cross-browser testing. This made me think about how different web browsers are tested which is something I have only done by manually checking that the application functions properly by going through the program as a user. In retrospective it makes sense that some automated tool can make this much easier and I would like to see how this works more.

I think one of the most important points the author makes (and states many times) is “do not aim for a 100% automation”, which makes sense as the author explains how it is not necessarily feasible or beneficial to have all of your tests automated. Furthering this point, the other interesting part of this article is how the author explains that manually testing is better for certain aspects of software. After reading these reasons, I completely agree with the author that certain areas such as testing the actual user experience of a program makes more sense to test manually instead of automating. Another aspect I really like about this article that I like is that the author continues throughout the article to focus on the practicality of automating testing from a business standpoint and takes into account the amount of investment and return on investment that can be gained by automated testing.

This article has certainly made me more interested in testing automation and I would like to see how tools implement this, especially in areas the article says can really benefit from this such as regression or browser testing.

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.

The end of a struggle…

The final week of the final project was a lot of fun and headache at the same time. My senioritis only got worse over last few days and my motivation to do any kind of schoolwork is at a lowest it ever been this semester. I have forced myself to do work and the project is pretty much done. Me and my group member still need to meet one final time to put finishing touches on everything and create a presentation, but I am not too worried about that.

The challenge this week was the backend code, to be more specific making it add new entries to the database we were using. The REST API we are asking to add things was having some problems with connecting to the database at first, connecting might be a wrong word to use here, the database was refusing the instruction and saying it is a read-only database. After some googling we have found the solution, the file with the database was in the wrong directory on the C:/ drive. It was somewhere where special permissions are required to modify it, making it read-only automatically. Solution: copy the file, move it to some new directory, adjust your connection path in the backend code. (thank you Stack Overflow).

The second challenge for this week came from the fact that me and my group member worked somewhat in parallel on our project(s) due to the conflicts in our schedules. Because of it we somewhat ended with two similar yet a little different project and the fun, and also a hard part, was to merge them into one working whole. We had a little bit different philosophy on how a certain aspects of the project should be done and making it all work together was challenging to say the least. Again, some quick google searches helped us tremendously and in my opinion the overall code should give us a good grade.

This project was a lot of fun and a lot oh headaches, but that is the way of software development, the end result might not always be a satisfying outcome but it is the journey that get us there that helps us learn and grow in this field. I came to a realization that I do not like working with databases or SQL, it seems a little to convoluted in my opinion and every little mistake might be a fatal one for a database. I will definitely stick to more modern programming languages and to working in the software development field.

From the blog #CS@Worcester – Pawel’s CS Experience by Pawel Stypulkowski and used with permission of the author. All other rights reserved by the author.

A Retrospective and Review of Unit Testing

Article link: https://dzone.com/articles/why-do-programmers-fail-to-write-good-unit-tests

In this blog post I wanted to examine an article I found about unit testing. I think that since unit tests were one of the first types of testing we learned about and we have used unit tests as a foundation for many other testing methods this semester, reviewing this article serves as a great retrospective (and provides another viewpoint) on the importance of unit testing and defining criteria on writing “good” unit tests.

In the article, the author defines the significance of unit tests in creating software. They then go on to define some various qualities that make for a “good” unit test. I agree with the listed points, but I think this article could benefit by providing a few examples of good unit tests and maybe a few bad ones for comparison, especially since this is an article about programmers not correctly writing unit tests. I also think the article could better define what these “units” that are being tested are, since this term is used frequently throughout the article. Additionally, I think the article should better define what specifically is being tested in these “units” besides just saying “examine and test each unit of code separately”. Again, this is where some examples would greatly help illustrate the author’s point. The article then goes to list many benefits of writing unit tests. It ends with an interesting (and great) point of how just having unit tests isn’t necessarily beneficial (and can even be detrimental) if they are poorly written.

Overall, I think that after learning about and using unit tests a lot this semester, that this article can serve as a good introduction to the topic, and it certainly reaffirms what I have learned about unit testing, but I also think it requires some revisions to be more helpful in demonstrating the points it makes, as I find it to be somewhat vague in the fundamental parts of presenting the main concept of unit testing. I think that having a well written article about this topic is especially important as this type of testing is used as the basis for many other types of testing we have learned about. I also think that this article could include this point of how unit testing is used in the larger contexts of other types of testing such as ensuring code coverage to further prove its importance.

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.

More on Static Testing: Bug-Finding Tools

In my previous blog for CS-443, I discussed my experience revisiting the class activity about static testing tools. I focused on figuring out the Checkstyle tool, which makes sure that the code complies with a set of style guidelines specified in an xml file. However, the class activity dealt with more tools than just Checkstyle. Today, I would like to look at the second part of this activity, which deals with tools that detect actual bugs rather than simple style issues.

The bug-finding tools that the activity focuses on are FindBugs, SpotBugs, and PMD. Much like Checkstyle, these three tools are extremely easy to add to a Gradle project by adding a few new lines to the build.gradle file. They each require just a single line to apply them as a plugin for the project. In addition, a small block of text can be used to set different properties for each tool, such as their version number. The activity also recommended adding lines to the options for FindBugs and SpotBugs to report their findings in an html file, since they use an xml file by default. This made the errors much more readable and easier to understand. Finally, a single line must be added to the Dependencies for SpotBugs to function.

Once build.gradle is properly configured, the tools are run simply by building the project (or calling “gradle check,” as I discovered). All three tools will then analyze the code and create reports explaining the types of errors they find. I ran the tools on the code provided for the activity, and I was surprised by how useful their reports were. They point out code that follows bad practice, code that may cause compatibility issues on different platforms, and even code that may negatively impact performance. I find it interesting that these tools are able to detect such errors without running the code, and I definitely see them being extremely useful as I often do not detect such errors myself even after hours of searching for problems manually.

Since these tools are so effective at finding errors, I was curious if there was even any benefit to using manual code review over one of these tools. I did a bit of research into this, and I found a blog post on synopsis.com that I think makes a great point – that these tools are unable to understand the context of potential errors in the same way that a human can. The blog also lists eight major limitations of these tools that should be considered when using them over manual review. Although static testing tools are able to find error in code quickly and easily, it is still necessary for the developers to determine whether the errors detected are valid or useful.

Link to the blog:

https://www.synopsys.com/blogs/software-security/static-analysis-tools-finding-bugs/

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.

Regression Testing

Article link: https://dzone.com/articles/what-is-regression-testing-and-why-is-it-important

Today I learned about regression testing from an excellent article on DZone and why it is an essential part of software testing. As the article explains, regression testing involves testing the whole software product to ensure that any changes to the code doesn’t break what was already working in the product or other parts of the software. The article then goes through a great example of how fixing a bug in one part of an example piece of software can unintentionally result in another (previously working) part of the system to stop working properly. The article demonstrates really well that this breakage can occur despite unit tests showing that the bug was fixed properly. This to me is an especially important point as it shows the value in using multiple methods of testing to ensure software is performing correctly. One criticism I do have of this article is that I wish they gave an example of how to implement regression (the article does include a link to a tool that performs regression testing) testing in an actual program (or in context of their previous example).

Although after reading this article, the concept of regression testing seems simple, I find it very important as both a software user and software developer. In my personal experience as a user I have seen everything from operating systems to video games release updates that caused features that worked fine previously to become buggy or stop working entirely. From the user perspective I know how frustrating this can be, so I am glad that I learned how to prevent this problem as a software developer. Regression testing is definitely something I now want to implement into my personal software projects. Now I need to look into the tools that can help do this.

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.

CS343 Final Project – Blog 1

Since this semester began, I’ve known exactly what I wanted to do for my final project, and even before the semester I’ve had this project kicking around my head. Ever since I saw my good friends personal site years ago, I thought it may be exciting to create my own, even before I even considered doing computer science. So, it should be obvious then, when I found out we would be creating a web page for our final project I knew this was the perfect opportunity to finally begin this project.

I knew that this personal – or rather, professional – site would be an interactive resume of sorts, a really incredible showing of capability that I could link to on resumes and in online professional profiles (LinkedIn, Handshake, etc). Consider this exchange:

“Have you done any web development?” asks a potential employer.

“Well sir/madam/neither, if you simply navigate to [web address] you’ll see the extent of that experience”.

“My goodness, this website looks amazing! I have no choice but to make you the president”.

As such it has to look good, like really good, you don’t become the president for nothing (you get it for being related to someone important). So, if I wanted a website that would make someone important adopt me, I needed to perfect the aesthetics of the website. I would need interactive elements and animations, a pleasing color palette, a readable layout, and of course sections on who I am and what my accomplishments are. I will, of course, not be linking this blog to it considering the beginning of this paragraph.

The first element I knew I wanted was a sticky header, or a toolbar that would “stick” to the top of the page once you scrolled down far enough for the top of the toolbar to touch the top of the page. This would mean that users could change page even while far past the header of the site. Another element I wanted was large tiles representing each page that would expand to fit the whole screen when clicked. However, I realized that it was incredible difficult to implement and also redundant considering I already had a way to access any other page at any point a user may be on said page.

I would reach the previous conclusion long after I had already begun, starting with the sticky toolbar. Folks online have implemented similar designs, so I began with those that were most effective and simple as a template. The way it works is actually very clever: a typescript method is used to check the yOffset of the page and if it goes past the offset of top of toolbar the toolbar is changed from a regular element to one that is fixed at the top of the page. As such, the elements on the page below would normally be covered slightly by this bar, however I have it dynamically add to the top-margin of the page to shift the content down appropriately. When this happens, by painstakingly finding the exact right values, it all appears perfectly seamless.

This work took, no joke, 4 hours or more, as I added scaling for page width such that when the page is shrunk horizontally as it would be on mobile the header and toolbar grow in height to accommodate the text and buttons correctly. However, I’ve already gone long on this blog so I will continue in the next one!

From the blog CS@Worcester – Press Here for Worms by wurmpress and used with permission of the author. All other rights reserved by the author.

Mutation testing

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

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

Path Testing

Path testing is a great way to ensure that your code is concise and understandable. It allows you to see the flow of your code and the direction in which it travels depending on conditions, loops, and the order of the code. The name is self explanatory you are essentially testing the “path” of the code. This kind of testing is not in the same field as something like a Junit test. This is a visual test that doesn’t use software persay. It’s more like a diagram that allows you to test and figure out the logic of your code. Here is a diagram I found online that helps explain this type of testing.

In this diagram you can see that the numbered nodes match up with the lines of code. This helps to make the details of the code abstract and to bring the path of the code into the forefront. This isn’t very detailed code but it shows how conditionals effect the path of your code. Certain nodes are passed through and others are not depending on these conditionals. Setting up these diagrams for your code can help you understand your code better and thus eliminate redundant testing or create more useful tests.

Here’s a link to a website giving a good explanation of path testing.

https://www.guru99.com/basis-path-testing.html

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

Final Project pt.2

Zac Loureiro

My last final project blog left off with us having a connection established between Java rest api and a SQLite database. We accomplished this through use of Java imports that were available to us. The next step was finding out how to actually access our database with queries that are sent with our backend Java rest api. We started with a simple get method, in the rest api format it is a @GetMapping method. We were just trying to run a query to get all the ‘artists’ in our database, ‘artists’ being music artists is one of the tables in our database. The query in SQLite would be “select * from artists”. There are a series of methods available with the sql imports in Java to help execute this query using the backend. Here is a look at our complete method:

@GetMapping(“/artists”)

public ResponseEntity<Object> getAllArtists() throws SQLException {

   PreparedStatement statement = conn.prepareStatement(“select * from artists”);

   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);

}

The line @GetMapping(“/artists”) establishes our path for the rest api. The lines PreparedStatement statement = conn.prepareStatement(“select * from artists”); 

and

ResultSet rs = statement.executeQuery();

are available via the sql imports. The first of these two lines creates the query as a variable “statement” of type “PreparedStatement” within our connection. Then a variable “rs” of type “ResultSet” is set equal to “statement.executeQuery()”. This sets “rs” equal to the result of the query, which in this case is all the artists in the database. Then the data of the artists is loaded into an ArrayList of type Map<String, String> and returned. Returning an ArrayList of Maps is best for functionality when we got to working on our front end code. Since artists had two fields “ArtistId” and “Name”, which are both Strings, saved the data in a Map<String, String> so that both variables were easy to access. This way we could pinpoint any artist in the database when we began to search for specific artists. Our next task was to create methods that allowed our users to search for a specific artist by name. We needed to also add a post method to allow users to add an artist to our database.

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.