While looking for something that I could use for my 5th homework, I started
looking into other software testing styles that we have not covered in
class. There are tons of different styles that are implemented to introduce
quality testing to software development. One such style I found this time is
called regression testing, a testing style created to combat resurfacing
bugs. Basically, regression testing is about implementing test cases every
update, and maintaining them throughout future iterations. This is done to
prevent old bugs from resurfacing and to check for any new bugs from being
introduced in every update. Test cases should be created and implemented
after every iteration to prevent bugs from piling up within your
software.

https://www.browserstack.com/guide/regression-testing

 While this may sound a lot like retesting , the main difference is
that regression testing looks for unknown bugs rather than known. How this
may look is the test cases are not for any specific bug but rather more
general to catch any problems that came about during the last change. Other
differences include the fact that regression testing can be automated, while
Retesting cannot. In order to remain vigilant, one should implement both of
these styles in order to avoid any problems from implementing new
changes.

https://www.browserstack.com/guide/retesting-vs-regression-testing

Some examples that I saw listed of regression testing tools include
Cypress, Playwright, and Puppeteer. These tools typically ensure that your
software and test cases work across different platforms and operating
systems. Last post I talked about how I found a website that uses A.I. to
write test cases, and considering how regression is already inclined to be
automated, I can’t help but wonder how long we have until we see an entirely
automated software development pipeline using regression testing. I think
it’s not too far in our futures.

In the article I linked above they give some examples of some regression
test cases. They use the classic shopping cart program and the test cases
are things like making sure the back end fetches the correct number of items
in the cart, or checking if the elements on the front end are still visible
despite scrolling down. These cases are general enough to catch both new and
old bugs on subsequent updates. For the Mars Rover kata we did in class an
example I could use would be updating the grid to be 100 squares big in each
direction, and then creating a new test case to check if it still wraps
around at the 99 mark.

From the blog CS@Worcester Alejandro Professional Blog by amontesdeoca and used with permission of the author. All other rights reserved by the author.

  While looking for something that I could use for my 5th homework, I started
looking into other software testing styles that we have not covered in
class. There are tons of different styles that are implemented to introduce
quality testing to software development. One such style I found this time is
called regression testing, a testing style created to combat resurfacing
bugs. Basically, regression testing is about implementing test cases every
update, and maintaining them throughout future iterations. This is done to
prevent old bugs from resurfacing and to check for any new bugs from being
introduced in every update. Test cases should be created and implemented
after every iteration to prevent bugs from piling up within your
software.

https://www.browserstack.com/guide/regression-testing

 While this may sound a lot like retesting , the main difference is
that regression testing looks for unknown bugs rather than known. How this
may look is the test cases are not for any specific bug but rather more
general to catch any problems that came about during the last change. Other
differences include the fact that regression testing can be automated, while
Retesting cannot. In order to remain vigilant, one should implement both of
these styles in order to avoid any problems from implementing new
changes.

https://www.browserstack.com/guide/retesting-vs-regression-testing

Some examples that I saw listed of regression testing tools include
Cypress, Playwright, and Puppeteer. These tools typically ensure that your
software and test cases work across different platforms and operating
systems. Last post I talked about how I found a website that uses A.I. to
write test cases, and considering how regression is already inclined to be
automated, I can’t help but wonder how long we have until we see an entirely
automated software development pipeline using regression testing. I think
it’s not too far in our futures.

In the article I linked above they give some examples of some regression
test cases. They use the classic shopping cart program and the test cases
are things like making sure the back end fetches the correct number of items
in the cart, or checking if the elements on the front end are still visible
despite scrolling down. These cases are general enough to catch both new and
old bugs on subsequent updates. For the Mars Rover kata we did in class an
example I could use would be updating the grid to be 100 squares big in each
direction, and then creating a new test case to check if it still wraps
around at the 99 mark.

From the blog CS@Worcester Alejandro Professional Blog by amontesdeoca and used with permission of the author. All other rights reserved by the author.

  While looking for something that I could use for my 5th homework, I started
looking into other software testing styles that we have not covered in
class. There are tons of different styles that are implemented to introduce
quality testing to software development. One such style I found this time is
called regression testing, a testing style created to combat resurfacing
bugs. Basically, regression testing is about implementing test cases every
update, and maintaining them throughout future iterations. This is done to
prevent old bugs from resurfacing and to check for any new bugs from being
introduced in every update. Test cases should be created and implemented
after every iteration to prevent bugs from piling up within your
software.

https://www.browserstack.com/guide/regression-testing

 While this may sound a lot like retesting , the main difference is
that regression testing looks for unknown bugs rather than known. How this
may look is the test cases are not for any specific bug but rather more
general to catch any problems that came about during the last change. Other
differences include the fact that regression testing can be automated, while
Retesting cannot. In order to remain vigilant, one should implement both of
these styles in order to avoid any problems from implementing new
changes.

https://www.browserstack.com/guide/retesting-vs-regression-testing

Some examples that I saw listed of regression testing tools include
Cypress, Playwright, and Puppeteer. These tools typically ensure that your
software and test cases work across different platforms and operating
systems. Last post I talked about how I found a website that uses A.I. to
write test cases, and considering how regression is already inclined to be
automated, I can’t help but wonder how long we have until we see an entirely
automated software development pipeline using regression testing. I think
it’s not too far in our futures.

In the article I linked above they give some examples of some regression
test cases. They use the classic shopping cart program and the test cases
are things like making sure the back end fetches the correct number of items
in the cart, or checking if the elements on the front end are still visible
despite scrolling down. These cases are general enough to catch both new and
old bugs on subsequent updates. For the Mars Rover kata we did in class an
example I could use would be updating the grid to be 100 squares big in each
direction, and then creating a new test case to check if it still wraps
around at the 99 mark.

From the blog CS@Worcester Alejandro Professional Blog by amontesdeoca and used with permission of the author. All other rights reserved by the author.

  While looking for something that I could use for my 5th homework, I started
looking into other software testing styles that we have not covered in
class. There are tons of different styles that are implemented to introduce
quality testing to software development. One such style I found this time is
called regression testing, a testing style created to combat resurfacing
bugs. Basically, regression testing is about implementing test cases every
update, and maintaining them throughout future iterations. This is done to
prevent old bugs from resurfacing and to check for any new bugs from being
introduced in every update. Test cases should be created and implemented
after every iteration to prevent bugs from piling up within your
software.

https://www.browserstack.com/guide/regression-testing

 While this may sound a lot like retesting , the main difference is
that regression testing looks for unknown bugs rather than known. How this
may look is the test cases are not for any specific bug but rather more
general to catch any problems that came about during the last change. Other
differences include the fact that regression testing can be automated, while
Retesting cannot. In order to remain vigilant, one should implement both of
these styles in order to avoid any problems from implementing new
changes.

https://www.browserstack.com/guide/retesting-vs-regression-testing

Some examples that I saw listed of regression testing tools include
Cypress, Playwright, and Puppeteer. These tools typically ensure that your
software and test cases work across different platforms and operating
systems. Last post I talked about how I found a website that uses A.I. to
write test cases, and considering how regression is already inclined to be
automated, I can’t help but wonder how long we have until we see an entirely
automated software development pipeline using regression testing. I think
it’s not too far in our futures.

In the article I linked above they give some examples of some regression
test cases. They use the classic shopping cart program and the test cases
are things like making sure the back end fetches the correct number of items
in the cart, or checking if the elements on the front end are still visible
despite scrolling down. These cases are general enough to catch both new and
old bugs on subsequent updates. For the Mars Rover kata we did in class an
example I could use would be updating the grid to be 100 squares big in each
direction, and then creating a new test case to check if it still wraps
around at the 99 mark.

From the blog CS@Worcester Alejandro Professional Blog by amontesdeoca and used with permission of the author. All other rights reserved by the author.

  While looking for something that I could use for my 5th homework, I started
looking into other software testing styles that we have not covered in
class. There are tons of different styles that are implemented to introduce
quality testing to software development. One such style I found this time is
called regression testing, a testing style created to combat resurfacing
bugs. Basically, regression testing is about implementing test cases every
update, and maintaining them throughout future iterations. This is done to
prevent old bugs from resurfacing and to check for any new bugs from being
introduced in every update. Test cases should be created and implemented
after every iteration to prevent bugs from piling up within your
software.

https://www.browserstack.com/guide/regression-testing

 While this may sound a lot like retesting , the main difference is
that regression testing looks for unknown bugs rather than known. How this
may look is the test cases are not for any specific bug but rather more
general to catch any problems that came about during the last change. Other
differences include the fact that regression testing can be automated, while
Retesting cannot. In order to remain vigilant, one should implement both of
these styles in order to avoid any problems from implementing new
changes.

https://www.browserstack.com/guide/retesting-vs-regression-testing

Some examples that I saw listed of regression testing tools include
Cypress, Playwright, and Puppeteer. These tools typically ensure that your
software and test cases work across different platforms and operating
systems. Last post I talked about how I found a website that uses A.I. to
write test cases, and considering how regression is already inclined to be
automated, I can’t help but wonder how long we have until we see an entirely
automated software development pipeline using regression testing. I think
it’s not too far in our futures.

In the article I linked above they give some examples of some regression
test cases. They use the classic shopping cart program and the test cases
are things like making sure the back end fetches the correct number of items
in the cart, or checking if the elements on the front end are still visible
despite scrolling down. These cases are general enough to catch both new and
old bugs on subsequent updates. For the Mars Rover kata we did in class an
example I could use would be updating the grid to be 100 squares big in each
direction, and then creating a new test case to check if it still wraps
around at the 99 mark.

From the blog CS@Worcester Alejandro Professional Blog by amontesdeoca and used with permission of the author. All other rights reserved by the author.

  While looking for something that I could use for my 5th homework, I started
looking into other software testing styles that we have not covered in
class. There are tons of different styles that are implemented to introduce
quality testing to software development. One such style I found this time is
called regression testing, a testing style created to combat resurfacing
bugs. Basically, regression testing is about implementing test cases every
update, and maintaining them throughout future iterations. This is done to
prevent old bugs from resurfacing and to check for any new bugs from being
introduced in every update. Test cases should be created and implemented
after every iteration to prevent bugs from piling up within your
software.

https://www.browserstack.com/guide/regression-testing

 While this may sound a lot like retesting , the main difference is
that regression testing looks for unknown bugs rather than known. How this
may look is the test cases are not for any specific bug but rather more
general to catch any problems that came about during the last change. Other
differences include the fact that regression testing can be automated, while
Retesting cannot. In order to remain vigilant, one should implement both of
these styles in order to avoid any problems from implementing new
changes.

https://www.browserstack.com/guide/retesting-vs-regression-testing

Some examples that I saw listed of regression testing tools include
Cypress, Playwright, and Puppeteer. These tools typically ensure that your
software and test cases work across different platforms and operating
systems. Last post I talked about how I found a website that uses A.I. to
write test cases, and considering how regression is already inclined to be
automated, I can’t help but wonder how long we have until we see an entirely
automated software development pipeline using regression testing. I think
it’s not too far in our futures.

In the article I linked above they give some examples of some regression
test cases. They use the classic shopping cart program and the test cases
are things like making sure the back end fetches the correct number of items
in the cart, or checking if the elements on the front end are still visible
despite scrolling down. These cases are general enough to catch both new and
old bugs on subsequent updates. For the Mars Rover kata we did in class an
example I could use would be updating the grid to be 100 squares big in each
direction, and then creating a new test case to check if it still wraps
around at the 99 mark.

From the blog CS@Worcester Alejandro Professional Blog by amontesdeoca and used with permission of the author. All other rights reserved by the author.

  While looking for something that I could use for my 5th homework, I started
looking into other software testing styles that we have not covered in
class. There are tons of different styles that are implemented to introduce
quality testing to software development. One such style I found this time is
called regression testing, a testing style created to combat resurfacing
bugs. Basically, regression testing is about implementing test cases every
update, and maintaining them throughout future iterations. This is done to
prevent old bugs from resurfacing and to check for any new bugs from being
introduced in every update. Test cases should be created and implemented
after every iteration to prevent bugs from piling up within your
software.

https://www.browserstack.com/guide/regression-testing

 While this may sound a lot like retesting , the main difference is
that regression testing looks for unknown bugs rather than known. How this
may look is the test cases are not for any specific bug but rather more
general to catch any problems that came about during the last change. Other
differences include the fact that regression testing can be automated, while
Retesting cannot. In order to remain vigilant, one should implement both of
these styles in order to avoid any problems from implementing new
changes.

https://www.browserstack.com/guide/retesting-vs-regression-testing

Some examples that I saw listed of regression testing tools include
Cypress, Playwright, and Puppeteer. These tools typically ensure that your
software and test cases work across different platforms and operating
systems. Last post I talked about how I found a website that uses A.I. to
write test cases, and considering how regression is already inclined to be
automated, I can’t help but wonder how long we have until we see an entirely
automated software development pipeline using regression testing. I think
it’s not too far in our futures.

In the article I linked above they give some examples of some regression
test cases. They use the classic shopping cart program and the test cases
are things like making sure the back end fetches the correct number of items
in the cart, or checking if the elements on the front end are still visible
despite scrolling down. These cases are general enough to catch both new and
old bugs on subsequent updates. For the Mars Rover kata we did in class an
example I could use would be updating the grid to be 100 squares big in each
direction, and then creating a new test case to check if it still wraps
around at the 99 mark.

From the blog CS@Worcester Alejandro Professional Blog by amontesdeoca and used with permission of the author. All other rights reserved by the author.

In the ever-evolving landscape of software development, ensuring robust security measures has become paramount. With the increasing frequency and sophistication of cyber threats, developers must incorporate stringent security testing protocols into their workflows to fortify their code against potential vulnerabilities. One such indispensable tool in the developer’s arsenal is JUnit 5, a powerful testing framework for Java. In this blog post, we delve into the realm of security testing in JUnit 5, exploring its significance, methodologies, and best practices.

Understanding Security Testing in JUnit 5

Security testing in JUnit 5 involves the systematic examination of code to identify and rectify security vulnerabilities. Unlike traditional testing, which primarily focuses on functional correctness, security testing scrutinizes the codebase for potential exploits and weaknesses that could be exploited by malicious actors.

Methodologies for Security Testing in JUnit 5

1. Static Code Analysis: Static code analysis tools such as FindBugs and SonarQube play a pivotal role in identifying security vulnerabilities in the codebase even before execution. By analyzing the code’s structure and logic, these tools can flag potential security loopholes, ranging from injection vulnerabilities to insecure data handling practices.
2. Input Validation Testing: Input validation is a crucial aspect of security testing, especially in web applications susceptible to injection attacks. In JUnit 5, developers can write test cases to simulate various input scenarios, ensuring that the application robustly validates user inputs to prevent injection attacks like SQL injection and cross-site scripting (XSS).
3. Authentication and Authorization Testing: Authentication and authorization mechanisms are integral components of secure software systems. JUnit 5 facilitates the creation of test suites to evaluate the effectiveness of authentication mechanisms, ensuring that only authorized users can access sensitive functionalities and resources.
4. Security Configuration Testing: JUnit 5 allows developers to test security configurations, such as HTTPS settings, encryption algorithms, and access control policies. By meticulously examining these configurations through test cases, developers can identify misconfigurations and strengthen the overall security posture of the application.

Best Practices for Security Testing in JUnit 5

1. Comprehensive Test Coverage: Aim for comprehensive test coverage to ensure that all critical components and functionalities are thoroughly evaluated for security vulnerabilities.
2. Regular Regression Testing: Incorporate security tests into your regression testing suite to detect regressions that could reintroduce previously patched vulnerabilities.
3. Utilize Mocking and Stubbing: Leverage mocking frameworks like Mockito to simulate external dependencies and stub out sensitive operations, allowing for isolated and controlled security testing scenarios.
4. Continuous Integration and Delivery (CI/CD): Integrate security tests into your CI/CD pipeline to automate the testing process and identify vulnerabilities early in the development lifecycle.

Conclusion

Security testing in JUnit 5 is an indispensable practice for safeguarding software applications against malicious threats. By employing rigorous testing methodologies and adhering to best practices, developers can bolster the security posture of their codebases, thereby mitigating the risks associated with cyber attacks. Embrace security testing as an integral part of your development workflow, and fortify your code against potential vulnerabilities.

For further insights into security testing in JUnit 5, explore the official JUnit 5 documentation here. Additionally, delve into static code analysis tools such as FindBugs here and SonarQube here.

From the blog Discoveries in CS world by mgl1990 and used with permission of the author. All other rights reserved by the author.

A topic we touched upon in class for a tiny bit was mutation testing. It is a different kind of software testing, where it alters your code and then runs your tests. If your tests fail, that means your tests are good. If your tests pass, that means your tests are not good. The altered versions of the code are called mutants, and if they are caught by the tests, as in failed, they are considered killed. If they pass, they are considered to have survived. The concept is strange, but can be effective, especially in finding inaccurate tests or seeing if you have enough tests.

In this blog post, Uncle Bob talks about his experience with mutation testing, how he came upon it, some benefits and how it works. He starts off by stating some issues with unit testing, such as writing enough tests, covering every line, branch, or path, and whether or not a test will fail depending on if you change some code. He answers these issues with sufficiency, coverage, and semantic stability, all of which can be solved by using mutation testing. It is fairly simple to run, and there is multiple ways to go about it. You run pitest tool, which alters your code a little bit, such as inverting if statements. It will do this more than once, where each variation of your code is a mutant. Then, for each mutant, it will run through all of your tests. If the tests fail, the mutant is killed, and if the tests pass, the mutant survived. Ideally, you want all of the tests to fail, which may be difficult to wrap your head around, typically you want your tests to pass. Having mutation testing is just another layer of testing to ensure your code is working properly. If a mutant survived, a number of things could have happened, such as ignored tests or discipline became too relaxed and people started writing sloppy code. Either way, it’s a good way to reinforce your tests and code. 

We did not really get to play around with this a lot in class, but it was cool to see how it worked. It had created multiple batches of mutants and might have ran the tests individually, but I may be wrong about that. If we had the chance to run it on code that we wrote, or if I had ran it on code that I wrote, maybe I could have understood it more. I will definitely use this in the future.

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

Performance Testing

Performance testing is the process of evaluating how a system performs under specific workloads. Responsiveness and stability of the system is monitored by examining the speed, reliability, and application size. Common indicators that are used for testing are network response times, number of users the system can handle at a time, processer memory consumption, and more.

Performance testing is an important part of the software development process. If an application is not tested before being released, users may have a negative experience because of errors that could have been found in the performance testing phase. Users that have a negative experience may be deterred from using the application in the future resulting in fewer overall users. Performance testing aims to find these errors before release, so users can have the best possible experience

When is performance testing done?

In software development, there are two main phases: development and deployment. Development testing focuses on individual components such as web services, APIs, and microservices. The earlier development testing begins, the earlier errors can be caught. Catching these errors early in the development phase is important because as the code base progresses, there is more and more code building on top of code that may have errors. This can make fixing the error more complicated. As the application becomes larger, comprehensiveness of the tests should also scale alongside. However, the application may get to a point where testing in the development phase becomes unreasonable and testing is done during the deployment phase. This happens when testing involves replicating a production environment, but recreating the environment is too difficult or expensive.

Types of Performance Testing

There are many types of performance testing that are done throughout the development process to verify the application performs as expected and can meet user requirements. Some of these performance testing types are:

• Load Tests – Tests the application under a realistic load by simulating virtual users. Response times are monitored, which can reveal potential bottlenecks to the system’s performance.
• Stress Tests – Similar to Load Tests, but the number of simulated virtual users is greatly increased. This is to see how the application runs when under peak activity.
• Soak Tests – Tests are conducted over an extended amount of time, as opposed to the tests mentioned above. This test is to evaluate how the system performs when under intense loads for a prolonged amount of time.

Conclusion

This article was chosen because it covered a variety of topics within performance testing, so I was able to gain a general understanding of what performance testing is. Performance testing is an important process in software development because it finds potential weak spots in a system. These weak spots can come from slow response times during peak activity, long load times, etc. Therefore, performance testing should be done on all systems to improve the user experience. In the future, I intend to look further into performance testing tools and frameworks to see how I can implement them in later projects.

Resources:

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

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