Hello and welcome back to my final blog post of the semester. As we have come to the end now, the last topic discussed in class was one of the most interesting in fact. The name alone, really sticks with you and catches your eye. But what does “Mutation Testing” mean exactly?

Mutation Testing is a type of software test in which you would change or “mutate” certain parts of the source code to see if your test code is adequate and is able to detect the proper errors in the code. Interesting concept here but how would this be done?

After coding the program and creating test code, we still need to figure out if the test code is adequate here. Therefore with this method, we would create alternate versions of the source code which is called a mutant with a single fault in each one to test how efective our test cases are. The test cases are then applied to these mutant programs and you must compare the result. The goal of Mutant testing is for the mutant to generate different outputs with the test cases and if it does not, then you keep the Mutant code alive and need to create better test cases until different outputs from the original are generated.

Now, the first thing that really came to mind when going through this idea was, “Wow, thats pretty interesting and it does make a lot of sense, ill start to try that from now on. But wait, this sounds like it could add hours to my programming, which seems pretty inconvenient so maybe not.” Inconvenient indeed, which is why Mutation testing more or less died after its developement in 1971 but with Automation tools like Stryker and PIT, mutation testing has once again picked up steam in the software testing world.

Sources: https://www.guru99.com/mutation-testing.html#:~:text=Mutation%20Testing%20is%20a%20type,fail%20the%20mutated%20source%20code.

From the blog CS@Worcester – The ways of the Computer: A Blog by JTekelis by jtekelis and used with permission of the author. All other rights reserved by the author.

Mocking is the process of just focusing on the code that needs to be tested not at all whats going on with the behavior of the outside dependencies. Therefore we sort of use a cheat code here, we use replacement objects ro kind of replicate the behavior of the real external more complex code. Immediately, this loophole has caught my attention as this seems like a great work around and will make my time creating test code much more efficient. And were all about efficiency when it comes to coding.

Back to the matter at hand, we should go over the three types of replacement objects. This objects include, Fakes, Mocks and Stubs. As a lot of information is rolled out onto us using these concepts i find it important to take a little time to really simplify what each of these terms mean.

A Fake is an object that has actual working code but returns a predicatable result, but “will not implement the actual production logic” (https://www.telerik.com/blogs/30-days-of-tdd-day-11-what-s-the-deal-with-mocking). In addition, a Stub is an object that will test specific inputs for some rather specfic results. The problem with a Stub is just that though, its too specific so once your begin to change inputs, the stub will begin throwing exceptions. Then lastly is where the much more sophisticated Mock comes into play. A Mock is similair to a Stub but also able to control how many times methods are called, in what order and with what set of data as well.

To conclude here, this overall concept of mocking using replacement objects, are used not to subsitute unit testing, but instead they isolate the dependencies, making test code more focused and efficient. There it is, efficiency, the holy grail of words when it comes to coding and that is the number one reason Mocking is used.

Source: https://www.telerik.com/products/mocking/unit-testing.aspx#:~:text=Mocking%20is%20a%20process%20used,or%20state%20of%20external%20dependencies.

From the blog CS@Worcester – The ways of the Computer: A Blog by JTekelis by jtekelis and used with permission of the author. All other rights reserved by the author.

When we went over Path testing in class a couple of weeks ago it really caught my eye. Could it be because it is a very visual topic/idea in a class consumed with code? This could lead to why this topic really stood out to me but also this idea made a ton of sense to me. It also made everything much clearer to me as it gave me a visual representation of what we were talking about, and as a visual learner, i love nothing more.

Path testing is a structural testing method that involves using the source code of a program in order to find every possible executable path.Since all code has multiple entry and exit points, testing for each of these points is time-consuming as well as a little complex at times. In order to maximize test coverage and provent yourself from testing for the same thing over and over again we use path testing to help us visualize and see the independent paths taking in the code to help us see what to test for.

A very basic idea here but a very effective one at that. Steps to this test are very bsaic as well though, as they include generating control graphs, which is kind of like a puzzle in the mix of all this that really clears everything up once you have solved it. You then find a basis set of paths and generate test cases for each path.

This process really helps you focus on the logic in the program, and really helps reduce your test code from testing for the same thing. And really makes you see all possible scenarios in which you should be making test cases for as well.

As a stronger visual learner, this concept really stood out to me when we were going over it and for others that sometimes get confused with the pages and pages of code involved here, this is a nice small change of pace to clear everything up.

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

From the blog CS@Worcester – The ways of the Computer: A Blog by JTekelis by jtekelis and used with permission of the author. All other rights reserved by the author.

After learning about decision tables in class, I feel like i started understandin what i was doing alot more. It really simplified everything in the programming down, and broadened my view of software testing.

According to this particular article, they explain that a decision table is “a black box test design technique to determine the test scenarious for complex business logic.” Basically, this table gives us a simplified visual version of all the various types of complex scenarios we should be testing for. This article then further goes into why all software testers should use one of these tables. The simplicity and complete coverage of the decision table highlight the reasons for use and honestly make a ton of sense. This table is complete, and it really broadens the view of the programmer before developing the test code rather nicely.

The article then further goes down to show us an examples of a decision table and like expected, made everything very easily. It sets up set of conditions which are binary, either yes or no(or true or false) and a list of rules to show us the various outputs.

The article lastly, goes down and explains how to read the decision table and how to use this information to interpret what we should show in our test code. It gives us expectations and a plan for our test code and honestly, what else more could you ask for.

Ultimately, the concept of this decision table is great, and for more visual people this works wonderfully and really will help in the development of test code.

Source:https://www.edureka.co/blog/decision-table-in-software-testing/

From the blog CS@Worcester – The ways of the Computer: A Blog by JTekelis by jtekelis and used with permission of the author. All other rights reserved by the author.

This whole class deals with the testing of software as it is one of the most important parts of programming. This particular article here tells us that although programming is perceived to rather bland and logical, in order to truly test our code we need to think outside of the box and show some real creativty.

Yes time and cost efficiency is very important as the author here explains, and that is why automated testing is rather important. With automated testing you can cover a majority of the code and can be executed pretty quickly.

The real creativty starts to come when talking about manual and exploratory testing. We go on to understand that although automated testing covers a large part of the code, there are still parts of the code left untested. This is where manual testing and the real creative mind of the programmer must come into play for very detailed and specific test cases for the original code. This creative mind usually come from past programming, personal experience and just intuition to truly test the entirety of the code and make sure it is functioning to the best of your ability.

The real meat of the article comes in the last section, when the article goes on to talk about exploratory testing which is the least restrictive version of testing. Although neglected due to time and budget constraints this is one of the most important activity’s in software devolpment is exploratory testing, essentially testing without borders.

He lastly goes onto to bring up a great point and extension of exploratory testing, and talks about Smoke testing. Essentially, smoke testing brings in someone else (whether it is a coworker, manager or casual trained end user) and brings in another set of eyes to check for things the initial programmer did not predict. This second pair of eyes offers even more random and spontaneous possible behaviors to truly test the absolute limits of the code and prevent as many bugs in the program as possible. Ultimately, this article does a great job in explaining that programming truly needs an artistic and creative set of minds, who can work together, to truly master and perfect a program.

source: https://builtin.com/software-engineering-perspectives/software-testing-creativity

From the blog CS@Worcester – The ways of the Computer: A Blog by JTekelis by jtekelis and used with permission of the author. All other rights reserved by the author.

Hello everyone, my name is Jordan Tekelis and I am begining my blogging career today as a senior currently enrolled at Worcester State University. I am starting this blog as part of the opening token assignments for CS-443 and look forward to working on these throughout the semester. For starters, I would assume the majority of my posts will be school and assignment related, but as time goes by and depending how confortable this becomes, I will keep an open mind in continuing this through out my professional career as well. But as for now, this looks to be the end for my brief introduction post and good luck to everyone this semester.

From the blog CS@Worcester – The ways of the Computer: A Blog by JTekelis by jtekelis and used with permission of the author. All other rights reserved by the author.