Category Archives: CS-443

The Long Road

To become truly good at programming is a life’s work, anongoing enterprise of learning and practicing.Ron Jeffries et al., Extreme Programming Installed This pattern from chapter three caught my attention, the quotes they used in the beginning of this pattern were nice and  sometimes we need something to remind us that the 1000 mile journey … Continue reading The Long Road

From the blog CS@Worcester – Shams's Bits and Bytes by Shams Al Farees and used with permission of the author. All other rights reserved by the author.

The White Belt

From the blog CS@Worcester – Shams's Bits and Bytes by Shams Al Farees and used with permission of the author. All other rights reserved by the author.

Mutation Testing Blog

Hello everyone! Today I wanted to write a blog about someone else’s blog post that I found online last week while reviewing for one of my final exams. Its by James White ( https://blog.scottlogic.com/2017/09/25/mutation-testing.html ) and in his blog he talks about mutation testing, which is one of the topics we’ve covered in class recently. Mutation testing is a way to test the code that you have written by altering your code with changes that are designed with the intent of being detected by different tests you have written for your code. Basically, it mutates your code so your tests can find the mutation and, if that happens, then you know your tests worked correctly. If the mutation survives in your code then you know the tests didn’t work.

What I like about James’ blog is that he makes the idea easy to understand, and incorporates plenty of different examples to walk readers through how mutation testing works. I specifically like his example of why mutation testing is needed, and how, in his example, mutation testing was able to point out a flaw in his code that otherwise would have gone unnoticed, since you could have changed the line of code or even deleted it all together and, without mutation testing, it would have looked correct even though it wasn’t.

The other thing I liked about James’ blog is the different examples he gives of what these mutations look like. How it can change (input > 0) to (input <= 0) or how it could mutate code to check true instead of false. I also liked how he addressed the common question of how long it would take mutation testing to run, since that is a question I had myself once we started learning about mutation testing. I also thought it was pretty cool that he mentioned how mutation testing can help point out instances of redundant code, and some other neat things about it too. Overall I enjoyed reading his blog, and it helped me better understand the material we learned about in class.

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

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

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&#039;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.

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&#039;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.

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&#039;s WebSite 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.