As this is the last blog I will be writing for this course, I thought it would appropriate to have it be about one of the final topics that I’ve learned; static testing tools. First of all, what is static testing? It’s a form of software testing that tests the code without needing to execute it. This method of testing is useful for finding and resolving errors during the early stages of the program. This also reduces the amount of potential errors that could appear during later stages of development. There are tools which are used to accomplish this form of unit testing that I’ve had some recent experience with. I’ve learned about a few of these static testing tools, and the ones that I would like to touch upon in this blog are checkstyle and Jacoco.

Checkstyle is one of the first static testing tool that I’ve used, and so I’ll talk about it first. The purpose of this tool is to check that the code being tested follows a specific coding guideline that has been preset. The process of doing so it automatic and so it allows the tester to be able to make sure that the coding standard is properly followed while also being able to save time of checking this themselves. While this tool can improve the quality in the presentation of the code, it can’t detect any coding errors having to do with the logic of the code.

Jacoco is a static testing tool that provides code coverage. It measures line and branch coverage by running various test cases, and displays the result with a visual report that shows which lines of code have been tested and the percentage of the amount of code that executes in each method. This allows the tester to be able to determine which parts of the code need more development.

Static testing tools are great resources for unit testing and can improve the overall development of the program by checking for errors at an early stage. These tools can be used simultaneously to check for multiple issues with a program at once. Checkstyle and Jacoco can both provide information to the tester that allows them to be aware of errors at each stage of the code, which makes the process of development more clear when building the program.

Useful links:
https://www.guru99.com/testing-review.html
https://checkstyle.sourceforge.io/
https://www.blueacornici.com/blog/code-coverage-with-jacoco/

From the blog CS@Worcester – CSBlogger by mjaber54 and used with permission of the author. All other rights reserved by the author.

Unit testing is a form of software testing where part of the software is tested and working. Recently I’ve been introduced to some methods of unit testing where a temporary object is created in place of an existing object in order to perform testing. The term for this is “Test Doubles”, as just like an actor in a movie has a double, doubles are created for objects in the program for the purpose of testing them. I’ve learned about different types of test doubles in my Software Quality and Test Assurance course, and I’d like to examine a few and give a brief explanation about how they work. The names of these test doubles are dummies, stubs, fakes, and mocks.

Dummy objects are made for the purpose of allowing methods to call an argument, and therefore they do not have any implementation themselves. These are used for methods are not actually important for your tests. For example, if you are trying to test a method and have it return something specific, then a dummy method can be created instead of making a method with code that isn’t relevant for the test.

Stubs, similar to dummy objects, are created for the use of testing code without needing to fully develop it. A test class is called to the stub, and the stub returns a value that is controlled. This is useful for scenarios where the result of the test changes depending on what the input is.

These test doubles make testing for code easier. They reduce the need of excessive code and allow for the methods in the test class to simply call the these test doubles instead. Each different test double has its own use depending on the objective you are trying to reach with your testing.

This article and blog provided very useful info regarding what each test double does and demonstrated each type of test double with examples.
https://dzone.com/articles/test-doubles-mockito
https://mokacoding.com/blog/swift-test-doubles/#:~:text=Dummy,the%20behaviour%20you%20are%20testing.

From the blog CS@Worcester – CSBlogger by mjaber54 and used with permission of the author. All other rights reserved by the author.

On my last blog post, I talked about boundary class testing and equivalence class testing. I want to once again share a new method of testing that I’ve learned about recently; path testing. This is a thorough way of testing your program. Instead of testing a wide variety of possibilities using a singular input, path testing navigates through the whole program, line by line, and makes sure that every possible path has been used at least one time. This ensures that if any error occurs, you can pinpoint where in the program the error is.

A program flow graph, or control-flow graph, is a form of path testing that visualizes a program using numbers that represent each executable line of code. This directed graph shows the order of which each code statement executes. For any conditions or loops, the graph demonstrates every possible outcome. This allows someone testing the program to locate precisely where an error in the code is held. It also makes it easier to understand the logic behind the loops and conditions in the program, as it allows you to see different results that would be executed depending on the set conditions. This also goes for loops, and you can see what part of the program that the code will loop.

This is an example of what a program flow graph would look like. The graph starts off at line 1 and continues down a straight path until 4. Line 4 is where the first condition in the program is located, and we can see that it either continues to line 5,6,7 and 8, or if the condition is not met, if goes to line 10. At line 8, the program loops back to line 4 to check the condition once again.

This is a simple example of program flow graphs. It is a very useful white-box testing method that is applicable when trying to track an error in a program. Compared to boundary value testing, which is a black-box testing method, path testing is a more detailed method to check for errors. Overall they are both useful techniques to have under your belt as a software developer, and understanding how each of these test methods work means growing as a computer scientist.

Useful Sources:

https://www.geeksforgeeks.org/path-testing-in-software-engineering/
https://www.guru99.com/basis-path-testing.html
https://ifs.host.cs.st-andrews.ac.uk/Books/SE9/Web/Testing/PathTest.html#:~:text=The%20objective%20of%20path%20testing,one%20or%20more%20new%20conditions.
https://www.geeksforgeeks.org/software-engineering-control-flow-graph-cfg/

From the blog CS@Worcester – CSBlogger by mjaber54 and used with permission of the author. All other rights reserved by the author.

As a beginner programmer, testing my code meant putting in a few inputs, and if the code ran then I had myself a successful program. Recently, I’ve learned of two better testing methods that give you the information needed to ensure that the program can run given any particular scenario. These are Boundary Value Testing and Equivalence Class Testing. While they do work differently, both of these methods are similar in that they each choose an input based on the pool of values given the set conditions.

In Equivalence Class Testing, the focus is on the conditions. Looking at the given conditions, we can determine which values are valid and which are invalid. The range of valid values as well as the range for invalid values are the pool of values that will be tested, which are divided into intervals. For each interval, given an input, if it passes then it stands to reason that all inputs within the range of values will pass for that interval. By the same reasoning, if an input does not pass, all inputs within the range will not pass.

For example, consider a program that is testing for a vending machine, with a variable named cash for the amount of money the machine can accept. The range of valid values for cash is 0 <= cash <= 100. Now if we put in a value for cash that is between 0 and 100 and it passes, that means all values between 0 and 100 will pass. Likewise, if the value does not pass, then all values between the range will not pass. All values below 0 and above 100 are invalid, so testing those numbers will result in an error.

Boundary Value Testing is similar, in that we take valid and invalid values and test them. The difference is that there are 5 particular values we are testing. Say that the pool of values are between 0 and 100 inclusively. The values that will be tested are:
1. the minimum valid value, 0
2. the maximum valid value, 100
3. a nominal value between the minimum and maximum, 20
4. a value just below the minimum, -1
5. and a value just above the maximum, 101.

These inputs test all possible scenarios, therefore if they all pass, then the program is successful. The minimum, nominal, and maximum values test all valid inputs, and the minimum below and maximum above values test invalid inputs.

Equivalence testing and boundary testing are both great methods to use when testing your program. They can both be used to test valid and invalid values, and by doing so, are capable of ensuring that a program is error free.

Helpful Source:

https://www.guru99.com/equivalence-partitioning-boundary-value-analysis.html

From the blog CS@Worcester – CSBlogger by mjaber54 and used with permission of the author. All other rights reserved by the author.

Software development isn’t all about writing code. A vital aspect of software development is quality assurance. Some may think that quality assurance is just all about testing the code to make sure it works. However, while that is a big part of quality assurance, there is more to it than that. As the name itself suggests, a quality assurance team ensures that the development of a product goes smoothly and without flaws. Testing occurs during each phase of development. They confirm that the end product is properly working before it releases.

Now of course sometimes you can’t have a whole team to certify that your code is perfect. Learning how to do QA on your own code is helpful as a programmer. This could include writing tests for your code, as well as making sure the code does not have anything unnecessary. Although this type of testing may not be an extensive as real Quality Assurance testing, it is still a good way to make sure that the program can run smoothly. There are many different forms of testing, some of which may be automated. Some developers feel that writing up tests for their code may take up more time than it is worth, so automation is an optimal solution.

Having quality assurance in software development increases the quality of the code and results in a more finished end product. It is an essential aspect of creating up to par software, and so being able to provide quality assurance to their code is something that every programmer should strive for.

Articles that provided useful information about quality assurance:

https://www.altexsoft.com/whitepapers/quality-assurance-quality-control-and-testing-the-basics-of-software-quality-management/

https://fortegrp.com/why-qa-is-essential-to-delivery-team/

From the blog CS@Worcester – CSBlogger by mjaber54 and used with permission of the author. All other rights reserved by the author.

Hello everyone, welcome to my first blog post! My name is Mohammad Jaber and I’ll be writing blogs for CS443 this semester. I’m looking forward to having a successful semester with everybody.

From the blog CS@Worcester – CSBlogger by mjaber54 and used with permission of the author. All other rights reserved by the author.