Category Archives: CS443

Test-Driven Development

Usually, the traditional method to developing code is to start with a design, implement that design, and then test the implementation to ensure that it runs as smoothly as intended. However, test-driven development (TDD) completely changes the software development process by emphasizing writing tests before code, turning tests into an iterative, ongoing practice.

Unlike the traditional waterfall model where testing is an end-of-cycle event, TDD integrates testing at every step. The TDD cycle consists of writing a failing test, implementing the feature to pass the test, and then refactoring the code. It’s deeply rooted in Agile principles, promoting iterative development, customer feedback, and adaptability.

Good adaptability comes from TDD’s ability to ensure that each development round begins with a clear, testable goal, which fosters collaboration and ensures that there is quality assurance in every phase. This is done by writing unit tests for core functionalities before implementing the feature. Once the feature is implemented, the code is refined to pass the test. Eventually, through iterative cycles, the entire application is built.

TDD offers numerous benefits for software delivery teams, including improved collaboration, robustness, and cost-effectiveness. Applications developed using TDD tend to be more robust due to the quick feedback loop, allowing bugs to be detected and resolved early on in the development cycle.

Moreover, by starting simple, organizing tests, regular refactoring, and building a comprehensive test suite, TDD leads to improved design and architecture, lowered long-term costs, increased confidence in code changes, and effective documentation.

Practicing the TDD method in class was an eye-opening experience. I was able to learn so much about testing and developing software at the same time. Because I am often guilty of neglecting to write my test cases, this type of development is good for getting me more comfortable and into the habit of writing stronger test cases.

Overall, TDD brings reliability, efficiency, and reduced maintenance costs to software development. Its structured testing approach, coupled with comprehensive test cases to optimize the development process, improving the code quality. TDD’s compatibility with CI/CD practices makes it essential for delivering reliable and high-quality software efficiently. I will definitely practice writing code using the TDD method more.

Source: Test-driven development explained by Jacob Schmitt

From the blog Stories by Namson Nguyen on Medium by Namson Nguyen and used with permission of the author. All other rights reserved by the author.

Week 10 Blog Post

Searching for an article this week I looked for something relating to mocking. Considering last week I did the negatives on mocking I think it’s valuable to have various perspectives. Seeing multiple ideas with mocking can give us an idea of how to implement them in the future. The writer of this article is a reliable source being a Java script developer. Getting information from someone in the industry can give a perspective inside the workforce and how people inside see different ideas. Not everyone may agree with using the same coding language but seeing how developers see different concepts can give an idea of the drawbacks to stuff and where in our own experiences can we improve. Overall this article is a great way to see how mocking is seen inside the workforce by an experienced professional.

In this article, Eric Elliot focuses on the drawbacks of excessive mocking. He points out how brittle tests and how they can be easily broken. There broken simply just from the change of implementation even though the behavior stays the same. Another point is a false sense of security because of there lack of accuracy that occurs from not using accurate real behavior. This is a fault in the test because the test will pass even if it isn’t supposed to. Third, he focuses on complexity overload which is just adding too much complexity can make the code harder to understand and maintain. Elliot still believes in mocking but a more balanced approach can overall help the program. Mocking should be used sparingly and when there actual weight for its use. All together Elliott wants the audience to create a strategy that will have confidence in their code correctness while also minimizing any negatives of excessive mocking.

Reading this article at first I thought it would be more of a pro mocking but it’s more in between. It says its flaws while still sharing the positives. After reading this article I understand that mocking can cut time but it can bring flaws to testing. The best time to utilize mocking is when time is scarce and later it can updated with time. It still isn’t the ultimate be-all to testing but with a balance, it will work. Understanding these flaws can foresee issues that may come up when mocking. Mocking should never bring up complexities that can complicate the code and should always have a priority in simple to understand and easy maintenance.

View at Medium.com

https://medium.com/javascript-scene/mocking-is-a-code-smell-944a70c90a6a

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

A Summary on Unit Testing

Unit testing is a crucial aspect of software development that focuses on testing individual components of a software product. Nickolay Bakharev writes a great article detailing the uses, advantages, and strategies to unit testing in his article, Unit Testing: Definition, Examples, and Critical Best Practices.

Unit testing involves writing tests for functions, procedures, methods, objects, or other entities in an application’s source code. The goal is to ensure that each unit of the software performs as intended and meets requirements.

Some advantages of unit testing are that it is able to detect problems early, thereby reducing costs. It is also heavily test-driven, easier to refactor the code, and allows developers to keep documentation of the system’s behavior.

Unit tests usually consist of four phases:

1. Planning and setting up the environment

2. Writing test cases and scripts

3. Executing the tests

4. Analyzing the results

A common approach to unit testing is something called Test-driven development (TDD), where tests are written before the actual code, resulting in a high-quality, consistent codebase.

Unit testing can also be used for security purposes by creating tests that focus on the security controls of the smallest testable unit of software. Security unit tests can help catch security flaws early in the development lifecycle which saves the costs of potential security breaches.

Various unit testing techniques include structural unit testing, which examines the internal structure of the code, functional unit testing, which tests the functionality of an application component, and error-based techniques such as fault seeding and mutation testing.

There are many examples of unit testing in specific frameworks. Some include Android unit testing, Angular unit testing, Node.js unit testing using Mocha, and React Native unit testing using Jest.

In order to use unit testing most effectively, the developer must write readable tests, write deterministic tests that always pass or fail on the same code, automate unit tests in a continuous integration process, and avoid multiple asserts in a single unit test to maintain clarity and reliability.

I found unit testing to be a very useful technique to learn in class. While I knew the basics of testing, this was the first time I actually implemented it into code. I will try to add these unit testing techniques to my research project code.

From the blog Stories by Namson Nguyen on Medium by Namson Nguyen and used with permission of the author. All other rights reserved by the author.

Week 8 blog Post

For this week I found an article about writing code considering we have been writing classes for the past few classes. The article I found stuck out to me because of its title “Writing Code an Art Form”. People always use the analogy of code being like learning a new language but I never heard anyone consider it as art. From the countless articles I could have chosen without this title, I may have never chosen it to begin with.

This article first starts with a background of how the idea of this article came to be. The setup was that the author was working as a junior developer who had to get a recently hired senior developer with 10 years of experience acquainted with their program. I can only imagine how that interaction was set up and whoever was leading the group should have probably reconsidered who should help the new employee. Even though the senior developer had far advanced experience his code was not easily readable. The author was even taken aback because the senior developer commented how the author likes to write pretty code. The author goes into detail on how poor documentation must be taken into account because other flaws can arise from bad naming conventions for variables/functions, spacing, and having the mindset to problem-solve. Keep the code easy to maintain, read, and debug don’t write spaghetti code.

Now reading this article gave me insight into the inner workings of the tech field. I would have never assumed that a new employee would be getting trained by the second recently hired. I would have assumed that someone with more experience with the project would have filled in the new person but maybe it could be that there both coming from similar places. Both of them are the newest employees and could be easier to help another person adapt to the environment. Reading this article has also reinforced ideas that keep your code simple and clean. My main takeaway was whenever you write code don’t just write it for yourself to understand but for everyone. Let’s say you are working on a project on your own you might just get enclosed in how you understand code nobody but you will be able to update it. Even if you don’t care that someone else will update it in the future your code can be so unreadable that future you may have no idea what you created. In a way, code is like writing notes and there is an art to writing good notes.

https://hinchman-amanda.me https://hinchman-amanda.medium.com/writing-code-an-art-form-e41e459bd2f6dium.com/writing-code-an-art-form-e41e459bd2f6

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

What is White, Black, and Grey Box Testing?

Software testing is broken into three main types: white, black and grey box testing. All three types have the same goal, however, they achieve these goals differently.

The blog “Black box vs white box vs grey box” from Shake does an excellent job in breaking down and explaining the unique roles of each testing type.

Black box testing:

The black box testing type focuses on the interface of the software. Software testers working with this type of testing approach the application from the user’s perspective. Because of this, no code of the program is required.

Usually, testers use the basic input/output technique to test the program, making sure that it is working as expected. The main goal of black box testing is to find usability issues and design flaws that affect the user experience.

White box testing:

While black box testing focuses on the user’s perspective, white box testing is all about testing how the program executes its function and therefore needs access to all the program’s code.

The main responsibilities of white box testing include identifying security vulnerabilities, evaluating broken paths, and testing outputs, loop errors, and data flow of the program.

This is achieve through the use of three main techniques:

Statement coverage — it ensures that every statement in the code is run and tested at least once. This process also identifies all the “dead code” or unused statements and branches.
Branch coverage — it is similar to statement coverage, but rather than individual statements, branch coverage ensures that all possible branches of the code are executed by detecting all the conditional and unconditional branches, then executing them.
Path coverage — this technique uses multiple test cases to cover every possible execution path through the software.

The purpose of these technique and white block testing as a whole is to reduce the risks of bugs developing later on development.

Grey box testing:

As the name suggests, grey box testing includes a combination of both white and black box testing. Testers approach the program from the user’s perspective, but with access to some of the internal structure of the program.

The goals of grey box testing include, examining the risk level of all variables in the software, identifying re-occurring errors, and optimizing the number and quality of tests by balancing coverage and effort.

Coming into CS443, the terms “white”, “black” and “grey” box testing were all foreign to me. While I had recalled hearing the terms being said, I never fully understood nor retained the concepts.

This article was very insightful in teaching me the concepts of white, black, and grey box testing. I think realistically, most software testing would be done in the grey box. This is because the advantage of grey box testing is taking the advantages of white box and black box testing. For a final thought, I hope to have the chance to do some white box testing to see what that would look like in a developer setting.

From the blog Stories by Namson Nguyen on Medium by Namson Nguyen and used with permission of the author. All other rights reserved by the author.

Strategies of Behavior Testing

There are many kinds of software testing, behavior testing is one of the more common types. Behavior testing involves a thorough evaluation of a code’s behavior through a controlled testing of inputs. By evaluating the outputs, the developer is able to verify that software is working as intended, to fix the bugs if not, and by doing so ensure that the program meets user requirements.

Because of the numerous scenarios in which a program may be used, it is important specifically in behavior testing to evaluate the code a thoroughly as possible. There are multiple ways to do this. In the blog “What is Behavior Testing in Software Testing?” from codiumAI, five main types of behavior testing strategies are covered. I will share the top three that I found the most useful and interesting.

Functional Testing
This is a foundational testing type and used in practically every type of testing not just behavior testing. In the context of behavior testing however, the goal of functional testing is to verify that the software performs the specified functions and actions as needed.

Specifically, functional testing aims to guarantee that the program complies with functional requirements, and when given certain inputs, that it generates the expected outputs. This can be done at the unit or system level to ensure that not only the software as a whole works, but also each individual component of code.
End-to-End Testing
After all the parts of a program are thoroughly individually tested, the next important step is to test how well all the parts work together to run the entire program. This is the purpose of end-to-end testing. The developers examine the flow of the entire program to make sure that all data and information are passed down through each module correctly and that there is seamless connection between each system.
Usability Testing
This type of testing is focused more the user experience. Usability testing, as the name suggests, focuses on the software’s user interface and overall user satisfaction. So, instead of checking for code bugs or input/output requirements, developers doing this type of testing are on the lookout for usability issues, poor layout, confusing navigation, or unclear instructions.

Usability testing ensures that the application not only runs correctly but is also intuitive and pleasant to use at the business/consumer level.

Out of the three strategies of behavior testing, I found usability testing the most interesting because it reminded me that the best applications are the ones that not only do their job, but also do it in an intuitive, user-friendly way. So as someone who is looking to so into software development, it is important to remember to look at the code from a user’s perspective, especially when doing software testing.

Blog: https://www.codium.ai/blog/what-is-behavior-testing-in-software-testing/

From the blog Stories by Namson Nguyen on Medium by Namson Nguyen and used with permission of the author. All other rights reserved by the author.

Path Testing

Hello, and welcome back to my blog.

This week I will be sharing what I have been learning about path testing. Path testing is a white box method of tests that is used to design test cases by using the source code of a program to find every possible executable path. The bug presumption for path testing is such that the program has gone wrong in some way, causing it to follow a different path than desired.

Path testing utilizes Cyclomatic Complexity to establish the quantity of paths, and then tests cases for each path are generated. Developers can choose to execute some or all paths through when performing this testing. Path testing techniques are perhaps the oldest of all structural test methods. Path testing is most useful for unit testing new applications.

It provides full branch coverage, but does so without covering all possible control flow graph paths. The four part process to path testing begins with drawing a Control Flow Graph of the software that is being tested. Next, Cyclomatic Complexity of the program is calculated based off Edges, Number of vertices, and Program factor. Now, we can use the data calculated in the first two steps to find a set of paths to test. The computed cyclomatic complexity equals the set’s cardinality. Finally, we will develop test cases for each of the paths determined in previous steps.

Path Testing process:

Path testing is beneficial because it focuses test cases on program logic. It helps to find all faults within the code and reduces redundant tests. In path testing, all program statements are executed at least once. Thank you for taking the time to visit my blog and join me on my growth as a software developer.

Sources:

http://www.mcr.org.in/sureshmudunuri/stm/unit2.php

https://ifs.host.cs.st-andrews.ac.uk/Books/SE9/Web/Testing/PathTest.html

https://www.geeksforgeeks.org/path-testing-in-software-engineering/

From the blog cs@worcester – Coding_Kitchen by jsimolaris and used with permission of the author. All other rights reserved by the author.

Silent Killers of Quality

Candice Coetzee’s article titled, “Eliminating the Silent Quality Killers in Your Organization” on Software Testing News covers several corners that companies often cut in order to bring their product to market which inevitably created bad organizational habits and setting them back in the long term. These silent killers of course all linked back to the Quality Assurance process and this article signals the necessary steps and organization can take to remediate these failures.

The first failure that the author points out is not having a software Quality Assurance strategy in the first place. She suggests making sure that every facet of your business has QA strategy from project management to development to operations. Another silent killer listed that could be business destroying is skimping on the software architecting process. The author insists that with thorough planning and implementation of things such as regression testing, debugging and logging a lot of the downstream failures will be reduced or virtually eliminated.

We increasingly hear more and more about products attempting to be agile but launching prematurely; Coetzee suggests that “building in some fat” around the QA time window can pay dividends down the road and minimize panel beating and fighting ever-growing fires of customer dissatisfaction with your customer service teams. She describes how these post-launch quality failures may not only be costly to a company’s bottom line but may cause irreparable brand damage. Sounds like a reason to always put quality first!

Cloudy Future for Mobile Testing?

Eran Kinsbruner’s article at DevOpsOnline.co.uk titled, “Testing Mobile Apps in the Cloud” discusses the recent push, advantage, and necessity of testing mobile applications in the cloud. Prior to the pandemic there was already a struggle to comprehensively test on all of the varieties of existing operating systems. Between unique vendor operating system variants for Android devices (Samsung, LG, Google, etc) and Apple devices (iOS, iPadOS) it was difficult enough to get these devices into the hands of every developer for testing in a single given office but with office spaces being shut down it became even less practical to do physical testing on these systems, queue cloud-based testing.

While there are many benefits to this cloud virtualized testing, the first I found to be the most impactful was the scalability of the operation. Being able to effortlessly spin up thousands of device instances to stress test is far more practical than buying however many of those devices. Not to mention testing the interoperability of varying operating system versions. Rather than having to keep multiple devices with older operating systems or rolling back to test compatibility one can simply boot up an instance with the older version.

Kinsbruner also points out the improvement to team communication and hand offs that come with cloud collaboration. By having a centralized cloud repository, it’s much easier for members in the production, testing or QA teams to observe and monitor program changes in real time using synchronous development environments so they can estimate what their task will be by the time it gets to them. It seems that this remote development and testing in the cloud may just be an integral part of the future of software.

Read the full article here

From the blog CS@Worcester – Cameron Boyle's Computer Science Blog by cboylecsblog and used with permission of the author. All other rights reserved by the author.

Getting Started With Python Unit Testing After Learning JUnit

Christian Shadis

CS-443 Self-Directed Blog Post #5

This past semester I have been spending a lot of time in my QA class working with JUnit 5. I want to be able to take my familiarity with JUnit and apply the same principles with unit testing in Python. I am leaning toward a data-centric career path and Python is widely used for data analytics, so this would be valuable information for me.

This post is not an expert-authored tutorial on Python unit testing because I, myself, am just getting started with it. In this post I will instead give tiny, bite-sized examples of just the basics, translating it from JUnit to Python unittest. I built identical, small classes in Java and Python, and will build tests to go with them. Below are the classes in Java and Python, respectively.

/**
 * Simple class with basic methods, written in Java
 * @author Christian Shadis
 */
public class main {
    public static void main(String[] args){
        int i = 0; // dummy code to keep compiler happy
    }

    public static int addTwoNumbers(int x, int y){
        return x + y;
    }

    public static String toCapital(String str){
        return str.toUpperCase();
    }
}

# Simple class with basic functions, written in Python
# Author: Christian Shadis

class main:
    def add_two_numbers(x, y):
        return x+y

    def to_capital(string):
        return string.upper()

Writing the unit tests in JUnit is simple: we import the JUnit assertions, and the @Test annotation. Then we create the test class, each of the two tests, setup, exercise, and verify just as always.

/**
 * Test Class for main.java
 * @author: Christian Shadis
 */
import static org.junit.jupiter.api.Assertions.*;
import org.junit.jupiter.api.Test;

public class maintest {

    @Test
    void testAddTwoNumbers(){
        int result; // setup
        result = main.addTwoNumbers(566, 42); // exercise
        assertEquals(result, 608); // verify
    }

    @Test
    void testToCapital(){
        String result; // setup
        result = main.toCapital("string"); // exercise
        assertEquals(result, "STRING"); // verify
    }
}

Luckily, writing unit tests is just as easy in Python as Java. We import the unittest library and the other class, define the class, and add a Test Case object as the parameter.

import unittest
from main import *

class maintest(unittest.TestCase):
import unittest
from main import *

class maintest(unittest.TestCase):

    def test_add_two_numbers(self):

        pass
    def test_to_capital(self):

        pass

Now we need a test case for each of our two functions, add_two_numbers and to_capital. Python’s unittest objects have very similar assertions as in JUnit. Use assertEqual(x, y) to check that x == y. This is the assertion we will use in this example, but any of the following are commonly used unittest assertions:

assertEqual
assertNotEqual
assertTrue
assertFalse
assertIs
assertIsNot
assertIsNone
assertIsNotNone
assertIn
assertNotIn
assertIsInstance
assertIsNotInstance

assertEqual takes two arguments and, as the name suggests, asserts their equality. See the implementation below:

    def test_add_two_numbers(self):
        result = main.add_two_numbers(33, 44)
        self.assertEqual(result, 77)

    def test_to_capital(self):
        result = main.to_capital("hi")
        self.assertEqual(result, "HI")

Run the tests and you will see them both pass. Below is a screenshot of the tests executing in Python and then in JUnit. As you can see, the Python tests are slightly faster than the Java tests, but not by much. I used IntelliJ IDEA and Pycharm IDE.

I have found the most helpful way to learn testing is to just play around with the unit tests, see what works and what doesn’t, see what causes failures and what those failures look like, and so forth. I would suggest any other beginner QA student to do the same. Playing around with different assertions and looking at the unittest documentation is a great way to learn this library. I hope this post gave you some insight on how to get started with unit testing your Python modules if you have done some work with JUnit in the past.

4/28/2021

Works Cited:
Unittest – unit testing framework¶. (n.d.). Retrieved April 28, 2021, from https://docs.python.org/3/library/unittest.html

From the blog CS@Worcester – Christian Shadis' Blog by ctshadis and used with permission of the author. All other rights reserved by the author.

Share this:

Share this:

Share this:

Share this:

Share this:

Share this:

Share this:

Share this:

Share this:

Share this: