Category Archives: CS-443

Static Testing Tools

hello, for the last time I have recently been learning about how to create application and use static testing tools. First of all I learned how to create an application with gradle. This is done by adding a few lines to the build file, the plugin for application and the path to the class with the main method. The binary to run the application will show up in the distributions folder. The next thing I learned was how to use check-style which is a tool for checking code style against a specific style sheet I used two different style sheets sun_checks and google_checks. These tools generate reports about your coding style based on the style sheet. I think these are very good for making sure you are writing clean code. The last tool I tried was spot-bugs which works similarly too check-style except instead of checking for style it checks for potential bugs and generates a report based on this.

From the blog CS@Worcester – Tim's WebSite by therbsty and used with permission of the author. All other rights reserved by the author.

Edge Testing

hello again, The next testing I learned was edge testing which is a combinations of boundary and equivalence. It tests to make sure each class results in the correct output and tests for errors at the boundaries. It is better in every way except one it has many times more test cases then either of the others. There are two types normal edge testing and robust edge testing. Normal only tests the valid side of each edge and robust tests the valid and invalid side of each edge.

Example with two variables x1’s edges a,b,c,d and x2’s edges e,f,g

  • Normal
  • x1: {a, a+, b–, b, b+, c–, c, c+, d–, d}
  • x2: {e, e+, f–, f, f+, g–, g}
  • Robust
  • x1: {a–, a, a+, b–, b, b+, c–, c, c+, d–, d, d+}
  • x2: {e–, e, e+, f–, f, f+, g–, g, g+}

From the blog CS@Worcester – Tim's WebSite by therbsty and used with permission of the author. All other rights reserved by the author.

Edge Testing

hello again, The next testing I learned was edge testing which is a combinations of boundary and equivalence. It tests to make sure each class results in the correct output and tests for errors at the boundaries. It is better in every way except one it has many times more test cases then either of the others. There are two types normal edge testing and robust edge testing. Normal only tests the valid side of each edge and robust tests the valid and invalid side of each edge.

Example with two variables x1’s edges a,b,c,d and x2’s edges e,f,g

  • Normal
  • x1: {a, a+, b–, b, b+, c–, c, c+, d–, d}
  • x2: {e, e+, f–, f, f+, g–, g}
  • Robust
  • x1: {a–, a, a+, b–, b, b+, c–, c, c+, d–, d, d+}
  • x2: {e–, e, e+, f–, f, f+, g–, g, g+}

From the blog CS@Worcester – Tim’s Blog by therbsty and used with permission of the author. All other rights reserved by the author.

Equivalence Testing

hello All, after I leaned about boundary testing in class I learned about equivalence testing. Which I think does a better job at testing for correct output in a program. However it does not do as good a job of testing for edge errors like out of bounds errors and such. The idea of it is to split each variable into a range for every output. These ranges are called Equivalence classes. There are two different conditions for testing it normal/robust and weak/strong. Normal only tests valid the valid equivalence classes and robust tests the valid and invalid equivalence classes. Weak only tests each equivalence classes once and strong tests all combinations.

These are graphs of the different types

From the blog CS@Worcester – Tim's WebSite by therbsty and used with permission of the author. All other rights reserved by the author.

Equivalence Testing

hello All, after I leaned about boundary testing in class I learned about equivalence testing. Which I think does a better job at testing for correct output in a program. However it does not do as good a job of testing for edge errors like out of bounds errors and such. The idea of it is to split each variable into a range for every output. These ranges are called Equivalence classes. There are two different conditions for testing it normal/robust and weak/strong. Normal only tests valid the valid equivalence classes and robust tests the valid and invalid equivalence classes. Weak only tests each equivalence classes once and strong tests all combinations.

These are graphs of the different types

From the blog CS@Worcester – Tim’s Blog by therbsty and used with permission of the author. All other rights reserved by the author.

The Flavors of Software Testing

Recently I took a final in my Software Quality and Assurance class. While I think the final went relatively well there was one question that has been haunting my dreams, hiding in every dark corner of every dark room I find myself in. The question was one so simple yet for reasons unbeknownst to me, I froze. A concept that, at a former point in my life in the not so distant past had been second nature to me. The question was “What is the difference between static and dynamic testing?” Since I failed myself and my professor on that test I felt like I should use this blog as a way to freshen up my understanding of both types of software testing.

I found myself seeking elder guidance on the matter and landed at the doorstep of Lakshay Sharma on the ToolsQA blog. A very short and simple read later I felt the rush of knowledge come back to me and I feel comfortable that I can talk on the matter of static vs dynamic, white vs black box testing. The blog made it very easy to understand the concept because it is laid out in a simple format: the first section explains static testing, and the second black box. After both sections there is a small graphic that shows the differences between the two. So, what is static testing anyways?

Static testing refers to software testing that is done without running the program. This testing is also called white box testing and is done prior to running the code and can help sort out a multitude of issues within the program. Things such as code structure, and code pathing can be tested at this stage and without the use of unit tests. This type of testing is beneficial because it forces developers to take a step back and review the code they are writing. If you’ve ever gotten into a groove while programming and then taken a step back to see the mess you just created you would know why static testing is such a good tool to have in your software testing tool belt. Static testing is full about preventing errors in the first place, and as the age old saying goes: an ounce of prevention is worth a pound of cure. While that prevention is great, in the event that you do get sick, you are going to want that cure as fast as possible and as strong as possible to get you back on your feet. This is where dynamic testing comes in.

Dynamic testing is the act of testing code while its running. Although while creating dynamic tests you may be able to see the code, dynamic testing falls under the umbrella of black box testing because the tests themselves do not care about the inner workings of a program. Dynamic testing tests behavior such as input/output. The good thing about black box testing is that tests can be written prior to developing code and give programmers an easy way to determine if a program is working as intended. Dynamic testing requires more time to set up than static since it involves actually creating test cases.

Just as life is made up of thesis and antithesis and one cannot exist without the other, static testing and dynamic testing go hand in hand and to use only one is to cheat yourself of the best possible work you could be producing.

 

From the blog CS@Worcester – Your Friendly Neighborhood Programming Blog by John Pacheco and used with permission of the author. All other rights reserved by the author.

Boundary Testing

hi, so I have been learning about how boundary testing works in my testing class and the different types, weaknesses and strengths. The basic idea of boundary testing Is between valid and invalid inputs. There are also two different conditions for it normal and robust normal being that it only tests the valid side of the border and robust meaning that it tests the invalid side too. There is also worst-case which removed the single fault assumption. The single fault assumption is that only one variable can be on a border at a time.

This is a picture of normal

This is a picture of robust

These are pictures of worst-case the left is normal worst-case the right is robust worst-case

From the blog CS@Worcester – Tim's WebSite by therbsty and used with permission of the author. All other rights reserved by the author.

Boundary Testing

hi, so I have been learning about how boundary testing works in my testing class and the different types, weaknesses and strengths. The basic idea of boundary testing Is between valid and invalid inputs. There are also two different conditions for it normal and robust normal being that it only tests the valid side of the border and robust meaning that it tests the invalid side too. There is also worst-case which removed the single fault assumption. The single fault assumption is that only one variable can be on a border at a time.

This is a picture of normal

This is a picture of robust

These are pictures of worst-case the left is normal worst-case the right is robust worst-case

From the blog CS@Worcester – Tim’s Blog by therbsty and used with permission of the author. All other rights reserved by the author.

Good Code Reviewing

For my final post for CS 443, I have decided to write about the code review process. I found a blog series on code review by Dr. Michaela Greiler, “The Ultimate Code Review Blog Post Series.” For this post, I will focus on the sixth entry, “A Code Review Checklist – Focus on the Important Issues,” which gives a very thorough checklist of issues to look for when reviewing code. The checklist includes many categories of issues: implementation, logic errors and bugs, error handling and logging, usability and accessibility, testing and testability, dependencies, security and data privacy, performance, readability, and experts opinion. Some of the items on the list include: following S.O.L.I.D. principles, proper testing, and is the code understandable and clean. While reading through the list I recognized a lot of topics that were raised in class and other CS classes. After reading through this article, I feel I have a better understanding of what to look for in code reviews. Before, I did not really know what to check for during the code review activity in class.

In the end, I highly recommend to others to give the entire series by Dr. Michaela Greiler a read through. If not, then maybe just a look through this checklist post. I know I have bookmarked this series and will likely come back to it for future reference.

Articles Referenced:
https://www.michaelagreiler.com/code-review-blog-post-series/
https://www.michaelagreiler.com/code-review-checklist/

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.

Junit 5 testing & testing with lambda expressions

hello all so in my software testing class I have learned about using junit 5 and using lambda expressions to test for exception throwing. I had used junit 4 before I learned this and I liked the way junit 5 makes it easier to make and test classes. I had an assignment to do testing an order system. I used the repeated test for testing auto incrementation. I also used lambda expressions to test for expressions and this was a ton easier then it was with junit 4. Below are two examples of the tests I wrote for that.

From the blog CS@Worcester – Tim’s Blog by therbsty and used with permission of the author. All other rights reserved by the author.