After getting through a couple weeks of my classes, and looking through blogs online about testing, I found the stickyminds blog. In my first week I was given setup tasks for CS-443 Software Quality Assurance and Testing, and one of those tasks was to discover blogs and podcasts related to the course content. I used this blog for my setup tasks, and found it a useful compendium of resources. While searching through stickyminds, I focused on the area around ‘new to testing’, and found a specific article about how to improve your skills as a performance tester quite interesting. The article’s title is How to Become a Better Performance Tester 101 by Jun Zhuang.

The blog begins with a small piece of advice based on segmenting code for testing. While some people might argue that you should test and optimize after large portions of the code are complete, this blog argues instead for doing performance testing while it is still incomplete. It is also advised to learn performance testing under someone who is very experienced in the topic, as many performance testers don’t understand or know which questions they should be asking. This is why shadowing is very important, as it allows a new performance tester to pick things up quicker, and gather an understanding of the tools used more effectively. Jun Zhuang discusses Agile software development teams that are commonly used in industry. He describes them as being used to handle performance testing responsibilities. These teams use strategies such as getting developers involved in capturing performance issues early, communication between teams and testers, and holding critical team meetings more frequently. They still face occasional struggles to meet deadlines when performance issues arise, but these teams are overall described as efficient and useful. The latter half of the blog explains the importance of performance testing, and why you should put this effort into doing it. By exploring these components like applications, or databases testers can better design tests and diagnose issues. The blog also shares some personal accounts of testers utilizing their knowledge in programming to speed up testing processes, by writing stubs and generating test data. It stresses the importance that individuals with diverse technological backgrounds, even if less experienced in performance testing, can bring valuable insights and problem-solving skills to the role.

I chose this blog because I am very interested in improving my skills at all times. When I discovered the Stickyminds blog, I was excited by the amount of information it presented. This blog on performance testing I discovered in the new to testing section, which has a lot of very useful articles to help you improve your skills. Even small pieces of advice and tactics can make the difference when it comes to coding and testing especially. A personal weakness with testing in my own projects I had, was that I was worried my code was not optimized enough, and what I learned through this blog is something I will apply to improving optimization, especially seeking out someone experienced to work with and improve my skills. 

Source:

https://www.stickyminds.com/article/how-become-better-performance-tester-101

From the blog CS@Worcester – WSU CS Blog: Ben Gelineau by Ben Gelineau and used with permission of the author. All other rights reserved by the author.

For this week’s blog post, I have chosen to discuss the blog “An Overview of Unit Testing” by Kayode Adeniyi; this article discusses the importance of unit testing, what it is, the stages of the unit testing process, as well as discusses some differences between automated and manual unit testing. I chose this topic for this week’s blog post because unit testing fits well within the issues we are discussing in this class; I also like how the author discusses the differences between manual and automatic testing.

The first topic the blog discusses is what unit testing is. “Unit testing is a testing method in software development where each individual part (unit) of an application is tested to analyze its proper working. This approach is pretty common and used by most development teams to verify the accuracy of each software component.” In my opinion, understanding what unit testing is is imperative, especially understanding that each test tests a part of a system, not the whole system.

The blog then mentions some key aspects of unit testing, which are, in part, why they are so helpful for developers in all fields of software development. The key aspects mentioned are debugging errors from the root, having reliable testing procedures, repeatability at every stage, and simplicity over complexity. The article also mentions that separating each part of a program makes it much easier to find and correct errors that appear as you are working on a project. The blog also discusses the steps in developing unit tests.

The first step of the test development process is planning the test. The blog describes this first step as “… [T]he developer defines the objective and scope of the testing. Once the unit of application is identified, the developer also defines the criteria for testing it. Critical thinking and effective planning is needed at this stage to ensure focused testing.” Due to this step’s importance in determining the functionality of the final test, it is one of the most essential parts of the test development process.

The next phase of creating unit tests is the creation of test cases. The blog describes test cases as scenarios where the units’ functionality is being tested. The blog also discusses edge cases or scenarios in which an unlikely event is to occur but still needs to be tested in the event where this unlikely event happens. The article defines an edge case as “… an occurrence of an extreme scenario during the normal expected working of any software. They are often the rare events that can happen when a user uses the software application.” While these events are unlikely to occur, if your project will be used by many people over a long enough period of time, these edge cases are an inevitability.

Blog: https://blog.logrocket.com/product-management/unit-testing-guide/

From the blog CS@Worcester – P. McManus Worcester State CS Blog by patrickmcmanus1 and used with permission of the author. All other rights reserved by the author.

Over the past few classes of the semester, we’ve gone over some of the terms as well as the methods used in software testing. Two of the methods that stood out to me were Black Box Testing and White Box Testing, mainly because I assumed they were methods that were closely related. We didn’t go in depth with these terms and methods but from what I researched and discussed with my group, my assumption was correct.

Black Box Testing is a method in which the software is tested without looking into how it works internally. Testers provide inputs then observe the outputs produced by the system. The goal is to evaluate how the system responds to “user actions that are both expected and unexpected.” This method can help identify defects, errors, and the like from a user’s perspective, as they usually have no knowledge of the inner workings of the software. This also means that testers don’t need a deep understanding of software testing or the particular code of the software; and as such, qualifications are not so important.

White Box Testing is a method in which the internals of the software are examined and tested. Testers examine everything within the software, such as the structure, logic, and code, and create test cases that assess that. This method is effective at uncovering issues with code quality and structure, bugs, and more that can’t be seen or evaluated with Black Box Testing. Like Black Box Testing, testers must ensure that the software meets specification. Unlike Black Box Testing, testers need a deep understanding of coding and software testing as well as that particular software being tested. 

I believe that both will be very important in the software development process, although I do lean towards White Box Testing having more impact. Those with specialized knowledge and skills will likely sort things out faster looking at the internals of the code than those without looking at just the inputs and outputs. It’ll generally be more effective as well as tests are done on the code and thus developers can quickly fix and solve those issues; whereas with Black Box Testing, it’s more of a way to acknowledge that there is some issue. I can only imagine Black Box Testing to be a very tedious and monotonous process although I could be completely wrong. It may be most effective to implement White Box Testing first and Black Box Testing afterward, as a double check of sorts.

Source: https://www.ranorex.com/blog/black-box-vs-white-box-testing-understanding-the-differences/

From the blog CS@Worcester – Kyler's Blog by kylerlai and used with permission of the author. All other rights reserved by the author.

During these first few weeks of class, we have been talking about JUnit and how it has features that allow us to test our code. We mainly talked about annotating methods to use as test cases as well as different assertions from Java and third-party libraries in order to help determine if a test was successful. While we kept using it throughout the week in order to help us test our code, I wasn’t exactly sure what JUnit actually was. Luckily when I was doing some research on it, I came across a blog on Parasoft by Nathan Jakubiak which gave a lot of useful information on what unit testing is, what JUnit is, as well as how to set up JUnit testing and to write different tests. I think that Jakubiak gave great descriptions as to what each of them are and what they are used for. Firstly, he stated “Unit testing is a form of white box testing in which test cases are based on internal structure. The tester chooses inputs to exercise particular paths through the code and configures assertions that validate the output. The purpose of unit testing is to examine the individual components or pieces of methods/classes to verify functionality, ensuring the behavior is as expected.” This means that unit testing is a type of testing where test cases are created based on certain parts of the program that you want to test, rather than testing the entire code in one test. For JUnit testing, Jakubiak stated “JUnit is the most popular Java unit testing framework. An open-source framework, it’s used to write and run repeatable automated tests.” Essentially he is just letting us know that it is an open-sourced framework that allows us to run different tests for our code. In his blog he also talks about how to set up JUnit testing which I personally don’t understand, probably because I just started working with it. However later in his blog he talks about all of the different parts of a JUnit test and how to write them. He also gave examples for some of the different parts, such as annotations, which I found to be really helpful in my understanding of the subject. I chose this Jakubiak’s blog because in all of the research I did on the topics of JUnit and Unit Testing, his blog did the best job of explaining them and overall gave me a much better understanding of the topics.

Link: https://www.parasoft.com/blog/junit-tutorial-setting-up-writing-and-running-java-unit-tests/

From the blog CS@Worcester – One pixel at a time by gizmo10203 and used with permission of the author. All other rights reserved by the author.

In the journey of continuous growth as a software developer, encountering plateaus is inevitable. It’s at these moments we must embrace “The White Belt” pattern from “Apprenticeship Patterns” by Dave Hoover and Adewale Oshineye. This pattern advises us to approach new learning opportunities with a beginner’s mindset, setting aside our deep-seated knowledge and expertise to foster new growth. I feel this applies to my current situation as I approach the end of school, I see an overwhelming amount on info and techniques to learn and need guidance on how to best absorb that.

The White Belt in Practice

The essence of the White Belt pattern is about humility and openness to learning. It challenges us to step back from our comfort zones, where we are recognized for our expertise, and dive into unfamiliar territories with the eagerness of a novice. This could mean learning a new programming language, adopting a different development methodology, or exploring a new technology stack.

Personal Reflection

What intrigued me about the White Belt pattern is its universal applicability. It’s a reminder that in the fast-paced tech industry, being comfortable with discomfort is a virtue. The pattern has reshaped my perspective on professional development, emphasizing that the journey is as significant as the destination.

Learning to unlearn has been a thought-provoking concept. It suggests that to truly master new skills or technologies, one must be willing to set aside preconceptions and past experiences. This approach not only accelerates learning but also fosters innovation and creativity.

Conclusion

The White Belt pattern has reinforced my belief in the importance of maintaining a learner’s mindset throughout my career. It’s a powerful reminder that to advance and innovate, we must be willing to embrace the fundamentals again, viewing each learning opportunity as a fresh start.

As I continue my journey in software development, I’m inspired to apply this pattern, seeking out challenges that force me out of my comfort zone, and approaching them with curiosity and openness. The freedom to be ‘foolish’ in the pursuit of knowledge is, paradoxically, a wise path to mastery and innovation. This applies very well to my current personal projects where I am working hard to learn new things like Flask app’s, Nginx, web databases, and API calls.

From the blog CS@Worcester – Abe's Programming Blog by Abraham Passmore and used with permission of the author. All other rights reserved by the author.

In the ever-evolving world of software development, JUnit 5 stands out as a beacon for Java developers aiming to elevate their testing strategies. My exploration into the depths of JUnit 5 was guided by an insightful article from Baeldung, which served as a comprehensive tutorial on this powerful testing framework.

Why JUnit 5?

My selection of JUnit 5 as a topic was driven by a desire to understand the latest advancements in Java testing frameworks. JUnit 5 represents a significant leap forward, offering new features and enhancements that promise to streamline the testing process for Java applications.

Insights from the Resource

The Baeldung guide to JUnit 5 provided a thorough introduction to its architecture, annotations, and assertions, which are crucial for creating efficient and effective test cases. It delved into the specifics of setting up JUnit 5, including Maven dependencies, and offered practical examples of its new annotations like @TestFactory and @DisplayName, which bring flexibility and clarity to test design.

One of the most compelling aspects of JUnit 5 that the article highlighted is its support for dynamic tests and the new assertion models that leverage Java 8 features, such as lambda expressions. This enables more expressive and powerful test cases.

Personal Reflection and Application

Reading through the article, I was particularly interested in the intuitiveness of JUnit 5’s approach to unit testing. The framework’s emphasis on extensibility and its modular architecture opens up new possibilities for custom test development. I anticipate utilizing these features to create more comprehensive and maintainable test suites in my future projects, ensuring higher code quality and reliability.

This deep dive into JUnit 5 has not only expanded my knowledge but also heightened my appreciation for the importance of advanced testing frameworks in modern software development. It has reinforced my belief in the value of continuous learning and adaptation in the tech industry.

Conclusion

The Baeldung article on JUnit 5 serves as an essential resource for any Java developer looking to stay at the forefront of testing practices. It offers both a solid foundation for newcomers and deep insights for experienced programmers seeking to leverage JUnit 5’s full potential.

For anyone interested in exploring JUnit 5 further, I highly recommend this article as a starting point. It’s an invaluable resource that combines theoretical knowledge with practical examples, paving the way for more efficient and effective testing strategies.

Read the full article on Baeldung: https://www.baeldung.com/junit-5

From the blog CS@Worcester – Abe's Programming Blog by Abraham Passmore and used with permission of the author. All other rights reserved by the author.

In the ever-evolving landscape of software development and its processes, version control systems play a pivotal role in ensuring code integrity when it comes to GIT, collaboration, and project management. Among these, GIT stands out as a distributed version control system with a rich history and a plethora of capabilities.

Going and delving deep into the fundamentals of GIT, i wanted to see the brief history behind GIT-i uncovered the facts of it being created by a man who went by the name of Linus Torvalds(the same guy who created the Linux kernel operating system). We explore how the GIT application revolutionized software development by supporting a non-linear process of operating within coding projects, being able to facilitate large project management as well as enabling code tracking. The blog post i went on was mostly a comprehensive guide to using GIT, the characteristics it has, the main components, commands which we’ve already covered in previous classes and activities alongside it’s various applications in other domains.

This seemed like a good choice considering it proves a sort of holistic view of GIT, of course another core feature that we use for software process management course- but more precisely being able to understand version control systems which is very crucial in the modern-day software development industry- providing valuable insights in terms of how GIT aligns with the key principals associated with software process management.

This resource does deepen my knowledge and understanding GIT’s role in software development and the uses/features- from the distributed model, branch management, better data integrity as well as being able to maintain parallel developments even in large code projects is an important takeaway from all of this. it can also be used for a variety of situations, whether it’s an open-source project, managing a product or handling real-time web pages and applications.

Since GIT is a useful application that i think will be an important part of future coding endeavors- i do expect to use it as a core tool taking into account it’s capabilities, the previously mentioned efficient branching to the merging and its distributed nature making it an essential resource and asset for maintaining quality code and ensuring good collaboration between team members. Knowing of it’s advantages and disadvantages helps to make informed decisions based on the situations one may encounter when using the application. To conclude with, GIT is a pivotal element in the world of software development. This resource provides a comprehensive guide to GIT’s features, characteristics, and applications- making this a highly powerful tool.

https://www.educba.com/introduction-to-git/

From the blog CS@Worcester – CSTips by Jamaal Gedeon and used with permission of the author. All other rights reserved by the author.

In software, we often hear the phrase git and caught up wondering what it is about. Here is a light description of what git is. Git is a distributed version control system (DVCS) that allows you to track changes in your codebase, collaborate with others, and maintain a complete history of your project. Developed by Linus Torvalds in 2005, Git has since gained widespread adoption due to its speed, flexibility, and robust branching and merging capabilities.

Before we dive into Git commands, it’s crucial to set up Git on your machine: That involves installation and configuration. This is where you Download and install Git from https://git-scm.com. Follow the installation instructions for your operating system and configure it using your name and email address using the following commands, git config –global user.name “Your Name” and git config –global user.email “your@email.com”.

When you move deeper into git commands, this is where it gets interesting playing around with these commands and getting to see what they can do. Some of the git commands include;

1. git init: Initialize a new Git repository in your project directory. This command sets up the necessary Git files and folders.
2. git clone: Copy an existing Git repository from a remote server to your local machine. For example, to clone a repository from GitHub.
3. git add: Stage changes for commit. You can specify individual files or use . to stage all changes in the current directory.
4. git commit: Create a new commit with the staged changes, providing a commit message to describe the changes made.
5. git status: Check the status of your working directory. This command shows untracked files, modified files, and files staged for commit.
6. git pull: Fetch and merge changes from a remote repository into your local branch.
7. git push: Push your local changes to a remote repository. This is essential for collaborating with others.
8. git branch: List all branches in your repository, and see which branch you’re currently on.
9. git checkout: Switch between branches or commits. To create a new branch and switch to it, use: git checkout -b new-branch
10. git merge: Merge changes from one branch into another. For example, to merge the changes from feature-branch into main: git checkout main and then git merge feature-branch
11. git log: View a log of all commits in the repository, including commit messages, authors, and timestamps.

As you go even deeper, you discover more advanced git commands such as ;

1. git stash: Temporarily save changes that are not ready for a commit. You can later apply these changes or clear the stash.
2. git rebase: Combine commits from one branch onto another, resulting in a cleaner commit history.
3. git reset: Unstage changes, move the HEAD to a different commit, or even remove commits from the branch entirely.
4. git cherry-pick: Select specific commits from one branch and apply them to another.

All these commands can also be found in a git installed terminal by typing git help in that event that you don’t have time to look for them on the Internet. In conclusion, Mastering Git and its essential commands is a critical skill for developers. Git enables efficient version control, collaboration, and project management. By understanding these core commands, you’ll be better equipped to navigate your software development projects, whether working solo or as part of a team. So, start using Git in your development workflow, and you’ll find that it’s an invaluable tool that streamlines your work and keeps your codebase organized.

From the blog CS@Worcester – MY_BLOG_ by Serah Matovu and used with permission of the author. All other rights reserved by the author.

In the vast landscape of software development, there’s an underlying principle that seasoned developers know all too well: code should not only work but should also be maintainable, readable, and scalable. To achieve this, we often find ourselves identifying and addressing something known as “code smells” and their close cousins, “design smells.”

Understanding the Essence

Let’s start with the basics. Code smells are those subtle hints in your codebase that something might be off. They’re like those faint odors in your room that you can’t quite pinpoint but know need attention. These “smells” indicate potential issues that can make your code harder to understand, modify, and extend (Fowler, 1999).

On the other hand, design smells are more like the underlying structural issues in your code that lead to code smells. If code smells are the symptoms, design smells are the root causes (Beck et al., 2002). Identifying and addressing design smells is essential for maintaining a clean and healthy codebase.

Common Code Smells

1. Long Methods: Code smells often start with overly long methods or functions. When a function becomes a novel, it’s difficult to follow, debug, or modify. Break down long methods into smaller, focused ones for clarity (Fowler, 1999).
2. Duplicate Code: Repeating the same code in multiple places is a classic smell. It leads to maintenance nightmares since you have to make changes in multiple locations when updates are needed (Fowler, 1999).
3. Large Classes: Just as long methods can be problematic, large classes or modules can become unwieldy. Split them into smaller, more cohesive units (Fowler, 1999).
4. Magic Numbers: Using hard-coded numbers without context is a recipe for confusion. Replace them with named constants or variables (Fowler, 1999).

The Path to Design Smells

Design smells often stem from issues in the overall architecture and structure of your code. Some common design smells include:

1. God Class: When one class knows too much and does too much, it becomes a “God Class.” This violates the Single Responsibility Principle (SRP) and makes the code less modular (Fowler, 1999).
2. Spaghetti Code: Unstructured and tangled code that’s hard to follow is like a bowl of spaghetti. It usually arises from poor planning and lack of separation of concerns (Kerievsky, 2014).
3. Circular Dependencies: When modules or classes depend on each other in a circular manner, it can lead to maintenance challenges and hinder code reusability (Fowler, 1999).

The Importance of Addressing Smells

Ignoring code and design smells is like letting that mysterious odor in your room linger; it won’t get better on its own. Instead, it can worsen over time and create a bigger mess to clean up (Fowler, 1999).

Addressing code smells and design smells early in the development process can save time, reduce bugs, and make your codebase more maintainable. It’s like opening the window to let fresh air in; your code will become more pleasant to work with (Fowler, 1999).

Conclusion

In the world of software development, understanding and recognizing code smells and design smells is essential for writing clean, maintainable, and efficient code (Fowler, 1999). Just as identifying that peculiar odor in your room can lead to a more comfortable living space, addressing these smells in your code can lead to a more productive and enjoyable development experience.

So, as you embark on your coding journey, keep your nose keen, and don’t hesitate to refactor and improve your code whenever you detect those telltale aromas of code and design smells. Your future self—and your fellow developers—will thank you.

References:

1. Fowler, M. (1999). Refactoring: Improving the Design of Existing Code.
2. Beck, K., et al. (2002). Extreme Programming Explained: Embrace Change.
3. Kerievsky, J. (2014). Refactoring to Patterns.

From the blog CS-343 – Hieu Tran Blog by Trung Hiếu and used with permission of the author. All other rights reserved by the author.