With software development, working in teams is typically normal. Being able to work in a team is important. But what is also equally important is interacting with stakeholders. A team does not make a project just because, typically someone comes up to the team and gives an idea and the team gets to work. That is an extremely watered down version of how it happens, but that is how it works. This can be somewhat confusing so let’s break it down. 

In this blog post, they talk about what a stakeholder is, why they are important and then some examples of a stakeholder. The post defines a stakeholder as a group of people or groups affected by a software development project. They are in the best position to offer specific input on needs at their level. Essentially, they are people who know what they want for this project and those whose interests are important for the project. It is important to get their input on the project because they guide the project in a way. They are able to create a list of things that are needed for the project and a way for the developers to figure out what they are working on exactly. You do not want to ignore the advice of stakeholders and neglect them, as that means the developers are just making the wrong thing. But who is considered a stakeholder? End-users are good to consider, as they are the ones to be using it once it is complete. Knowing their input and how it affects them is important. People like managers, project managers, developers, and partners are all important, as they ensure that certain aspects of the project are doable. Certain authorities are also important to consider, such as shareholders or company owners. It is hard to get everyone in for a meeting on the project all at once, so getting representatives is a better alternative. Determining whether or not their input is needed is also important, as to not waste someone’s time. But again, how do you determine that? There are some questions you can ask, such as “who will be affected by this product,” “how will workflows change,” and “are there any people whose support is vital to the project.” 

Understanding who has valuable input and is able to shape the project will be key to you as a developer, as it lays the foundation and blueprint for what you and your team will be doing. It may be difficult to get everything everyone wants, and you may have to cut some things. But knowing when to do so is up to you and the team.

From the blog CS@Worcester – Cao's Thoughts by antcao and used with permission of the author. All other rights reserved by the author.

What is JUnit?

JUnit is an open-source framework used for automated unit testing in Java. Unit testing involves testing small, isolated units of code to verify that they function as expected. These units could be individual methods, classes, or even a line of code.

When developers write code, they also write tests for that code using JUnit. These tests are then run automatically, checking for any deviations from expected behavior. JUnit provides feedback in the form of pass or fail results.

Why Unit Testing with JUnit?

Unit testing, facilitated by JUnit, offers several benefits:

1. Early Bug Detection: By writing tests before or alongside the code, developers catch bugs early in the development process. This ensures that issues are addressed promptly and doesn’t propagate further.
2. Code Reliability: Writing tests encourages writing modular, well-structured code. This leads to more reliable and maintainable codebases.
3. Confidence in Changes: With a comprehensive test suite, developers can refactor or modify code confidently, knowing that any breaking changes will be immediately flagged by failing tests.

Features of JUnit

JUnit offers several features that make it popular among developers:

1. Open Source: Being open source, JUnit is freely available for developers to use and contribute to. This fosters a vibrant community and ensures continuous improvement.
2. Annotations: JUnit provides annotations to identify test methods, setup, teardown, and more. These annotations make test code more readable and maintainable.
3. Assertions: It includes a set of assertion methods to validate expected outcomes. These assertions help in comparing actual results with expected results.
4. Test Runners: JUnit has test runners that execute tests and report the results. It supports different types of test runners for various testing scenarios.
5. Automated Test Running: Tests run automatically without manual intervention. This saves time and effort and provides quick feedback on the code’s health.

JUnit Annotations

Annotations in JUnit provide metadata to methods to control their behavior during testing:

• @Test: Marks a method as a test method.
• @Before: Executes before each test method.
• @After: Executes after each test method.
• @BeforeClass: Executes once before any test method in the class.
• @AfterClass: Executes once after all test methods in the class.

Conclusion

JUnit is a vital tool for Java developers, ensuring code quality, reliability, and maintainability. Its features, including annotations and automated testing, make it invaluable in modern software development.

By understanding JUnit and incorporating it into your workflow, you can write better, more robust Java code. Embrace automated testing with JUnit, and watch your code quality soar!

Source: https://www.simplilearn.com/tutorials/java-tutorial/what-is-junit

From the blog CS@Worcester – CS: Start to Finish by mrjfatal and used with permission of the author. All other rights reserved by the author.

Object-oriented testing is about ensuring that the object-oriented software works as it should. Testing is important in any project so it’s important to make sure that the code isn’t buggy or crashes. Object-oriented testing has specific techniques that test our object-oriented program by focusing on what matters the most like unit, subsystem, and system testing. Unit testing breaks down each class and test, it helps catch errors and figure out if things are talking to each other as they should be. Subsystem testing is like testing a group of classes together, it shows how they work as a team and how it handles anything outside of it. System testing makes sure to test everything in the system and check if everything works together, leaving a top-notch system. When it comes to object-oriented testing it’s important to look out for bugs, test everything, and clean code sooner rather than later. Testing is about finding any bugs and errors that can be fixed, so looking for those bugs would help solve any problems the software has.  Instead of cleaning up the code after it’s completed, it’s useful to test it early and keep at it so that the issues are fixed sooner rather than later.

I felt like object-oriented testing has given me more information about testing and even though I know that there are different types of testing it’s given me a better idea of how they work. This reading is important for software developers who would rush through their work and not practice clean code because it emphasizes testing earlier to find any errors and clean up code that could make it confusing for other software developers. The reason why I chose this topic is because object-oriented testing is important in software development and without this information, it can cause a lot of problems and more work for developers to do when it’s avoidable and fixable. Object-oriented testing plays a huge role in software development making it important to know how it works and what is easy to detect. It also teaches software developers more about clean code and makes sure that the code is readable and understandable for other developers.

https://goodpractices.home.blog/2019/11/27/object-oriented-testing/

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

Going into my future projects, especially those for my summer fellowship, I have taken a distinct interest in Python. Throughout this course I have learned a great deal of how to test for object oriented compiler languages, using Java as our learning tool. I have wondered how testing might differ across different languages. And with a large project in Python coming up, I’d like to prioritize doing this the right way. I would like to practice in python testing to prepare. Luckily, recently posted last week, there was an article on the home page of Stickyminds surrounding python testing. The article’s title is Ensuring Reliable Cloud Applications: A Guide to Testing State Machines with Python by Konstantin Sakhchinskiy

Testing state machines in cloud applications involves heavy use of APIs. Python scripting is effective to help to ensure reliability, performance, and resilience. This is one way that an efficient library-heavy scripting language like Python would be useful for cloud applications. It is very effective at being implemented for many applications now utilizing the language itself, if only as an effective testing language. In the case of a cloud app for example, managing external browser profiles for automation and web scraping, users interact via API to execute their needed functions. Python can be used to expedite this process, as a way to manage state machines necessary to operate this cloud app. General approaches to testing on these state machines include separating output generation from state transition logic, focusing on individual states and transitions, testing each possible state transition, exploring boundary conditions, testing resilience to invalid input or disruptions, and checking system interaction within the broader context. The article also mentions some key tactics for mastering state machine testing, including testing for race conditions, assessing external disruptions and network challenges, handling heavy loads, and understanding technical details such as hidden states. Python scripting can automate testing processes. Using asyncio and httpx, scripts can simulate user interactions with the cloud service, testing responsiveness. Tailoring tests to specific needs and monitoring system performance using tools like Grafana and Kibana are essentia, and made more efficient with Python’s wide variety of usable systems. Overall, testing state machines is crucial for ensuring application reliability, and Python scripting offers effective ways to automate and simulate real-world scenarios for comprehensive testing.

My view on testing applications was expanded greatly by this article. The prevalence of automated testing libraries throughout other languages to enforce scripting was a surprise to me. And this article has helped me to understand the real role of specific and intentional testing of software. I was also surprised to find that state machines were very important to understanding how to test and break down code, as this is something I learned a lot about in the fall. I am not working with external applications or languages outside of Python for this project, so I will not utilize these libraries to automate my testing, but going forward this knowledge is imperative.

Source:

https://www.stickyminds.com/article/ensuring-reliable-cloud-applications-guide-testing-state-machines-python

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.

Performance Testing is a subject I just recently discovered is included in the Software Quality Testing umbrella term. Outside of casually monitoring CPU and GPU usage while using demanding software, I have little knowledge of what Performance Testing is. As a future worker in the Computer Science field, knowing how to report and minimize hardware stress must be an invaluable skill.

During my search to understand what Performance Testing is, I found an article written by Tricentis that included an in-depth explanation for each step (or deviation) of Performance Testing. Before going into detail, Tricentis highlights that performance testing is a direct solution to ensuring the stability and scalability of software. If performance testing is ignored, then users may encounter issues with speed, crashes, or data loss within their application. Testing seems to flawlessly integrate with CI/CD models, as testing should occur whenever a working model is available. This allows the development team to fix issues early before they sink too deep into the product’s foundation. Within the realm of performance testing, some subtests aim to find results for specific metrics. A few that I was unfamiliar with are as follows. Regression tests seek to test two states of the program, one being the current model, and the other being one with experimental changes. Both of these models work together to compare the hardware performance. These are used to highlight whether changes from the most recent version are more damaging to the product. Functional tests focus more on the software aspect of the product. Using this test will yield results on whether the UI elements, APIs, etc are all functioning correctly. Lastly, load testing seeks to put the product under great stress by simulating several concurrent users. Testing with this will give the developers insight as to how their product will function once published to the general public. Metris from load testing will help reinforce the product before it can fail after its initial release.

Performance testing will yield several useful metrics to guide the development of the product. These metrics include hardware bottlenecks, response time, and load time. Issues about these metrics must be addressed during the development process as they directly impact the reliability of their product post-release. Untested hardware is an active detriment to the developers, and will further damage the development process. Following the idea of testing software ‘frequently and consistently’, developers must also view how the current state of their product affects the hardware it will operate on.

-AG

Source: https://www.tricentis.com/learn/performance-testing

From the blog CS@Worcester – Computer Science Progression by ageorge4756 and used with permission of the author. All other rights reserved by the author.

JavaScript is a programming language completely foreign to me. At one point in the near future, I see myself learning the basics just to gain general exposure to it. It differs enough from my first object-oriented language, that being Java, to the point where it seems valuable to have some experience in it. With this in mind, I began my search to see what testing framework would work for this language and how tests are conducted differently.

In my search, I discovered this testing framework named Jest. This is a testing framework that is most known for testing Javascript but has also seen usage with other languages such as Angular and React. According to the author of the blog post The Pros and Cons of Different Test Tools – Jest, Craig Risi, he immediately states this testing framework is much more user-friendly than others. Jest does not require the users to install packages or other external dependencies, as the framework has them already included. Furthermore, the included dependencies are often built on frameworks of other languages, such as Mocha or Chai, which makes Jest an incredibly flexible testing framework. An important inclusion Risi made to his blog post was the inclusion of all features Jest offers out of the box. These range from topics I’m knowledgeable of, such as Mocking and Unit Testing, and some that I’m new to, such as Snapshot Testing and Asynchronous Testing.

Towards the end of Risi’s blog post, he mentions the direct pros and cons of using Jest. As previously mentioned the versatility between languages, easy start-up, and abundant features are a testament to its practicality. Unfortunately, no testing framework is flawless. Several of these issues originate from the sheer size of Jest. Downloading this framework and testing smaller projects offer an issue of scalability. There are countless smaller frameworks, in terms of digital size and complexity, that are better suited for testing software. Additionally, all the features Jest includes come with their own learning curve. Users may never utilize some features as the scope of their testing does not call for Jest’s extensive collection. With both the pros and cons in mind, Jest is incredible in what it can achieve but development teams must consider the scale of their project to determine whether using it is appropriate. Reflecting on my experience with testing frameworks, I can understand the value of having that much utility from one framework, yet I don’t see myself creating a project ‘so big’ that would call for it’s entire library of features.

-AG

Source: https://www.linkedin.com/pulse/pros-cons-different-test-tools-jest-craig-risi

From the blog CS@Worcester – Computer Science Progression by ageorge4756 and used with permission of the author. All other rights reserved by the author.

In last week’s class, we were tasked with creating an activity related to our course material. Our group decided on behavior-driven development (BDD) since it is related to test-driven development, which we discussed in class. BDD’s approach is user-focused and prioritizes understanding between the development team and users, but it has yet to be discussed in class. Since the post was well-organized and informative, focusing on aspects that could help developers improve their code, I decided to talk about BDD for my blog post this week. 

The blog post “Behavior-driven development principles and practices,” by Philip Rogers outlines the basics of BDD, detailing its history, principles, and practices. Phillip explains that BDD is centered around three principles: what the software could do, what the software should do, and what the software does.

1. What the Software Could Do: This principle involves understanding what the customer wants from the software. They use discovery workshops to outline what the developers should prioritize and resolve any confusion between the users behaviors and the team.
2. What the Software Should Do: This principle focuses on creating documentation in a human and computer readable format. This includes the given-when-then format that describes the user’s behaviors and how the software should respond. 
3. What the Software Does: This principle focuses on using the documentation or scenarios to create automated tests and improving the code until it aligns with the customer’s requirements and the team’s goals.

The blog post also discusses Gherkin, a language used in BDD to bridge the gap between human and computer understanding. The syntax used in Gherkin helps capture user scenarios and articulate how the automated tests should work to align with those scenarios. Philip also explains the benefits of BDD, such as improved collaboration and reduced rework, and the cons, including high level of business engagement and the lack of compatibility with traditional software development. 

After reading this blog post, I better understood the BDD process and why these principles are in place. It highlighted why there would be a need to deviate from or expand test-driven development. There should be a focus on how users interact with the system using communicative language to reduce the creation of faulty features.  

In the future, I plan on being mindful of the user’s experience and creating software with my team to meet the users and, in turn, the team’s expectations. I will also look into a Gherkin and try to understand the syntax better to produce better tests and end products. 

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