Category Archives: CS-443

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.mehttps://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.

Improving In Software Testing

Unfortunately, just weeks after exploring test-project’s blog, it was shut down and replaced by a new blog in Tricentis. I was disappointed to find that I could no longer utilize this great resource. In searching however, I found that test-project was on its way out as far as automated testing goes, and this reaffirmed to me the ever changing world of software. In response I looked for blogs to improve my testing skills individually once more, and explored stickyminds again. The article I chose explained how practice can affect your software testing skill. The article’s title is Repetition in Practice by Justin Rohrman.

The article explores the pivotal role of repetition and practice in software testing, just as you would need in any other interest, like music. The author mentions his own experience with music in fact, and used his practice with music to inspire his software testing strategies. The article highlights the significance of deliberate practice in honing testing skills, advocating for an adaptive approach that considers the unique context of each testing scenario. A large failing of many software developers is the lack of practice, or lack of practice strategies. The article delves into some various methods for practicing software testing, to show how it connects with other interests. The most effective method introduced in the article is the ability to relate your own testing specific goals to other interests. For example: Heuristics is mentioned, and the author mentions if you like ‘Scrabble’ to play scrabble while thinking of heuristics and apply them to Scrabble. This will improve your skill in heuristics and allow you to improve it in your testing. This is an excellent strategy to help the mind focus on coding when other interests take priority. Overall the article emphasizes the importance of maintaining a growth mindset and embracing opportunities for learning and experimentation to refine testing proficiency. Outside of the article itself, there is a very valuable comment made by Michael Larsen. This comment mentions how testing is more subjective and abstract, and that it’s important to persevere when practicing. This is because unlike things like music, there are very little measurable improvements that you can see yourself, and you often have to wait for others to notice the improvements. This was an excellent thought provoking comment.

Through the CS-443 course, I have been considering how testing will play a role in my professional career and how I will develop these skills along with development. These kinds of practice strategies give me an engaging way to turn my brain into the mindset to code. This is very valuable to me, as often I can get very distracted. To be able to turn distractions into sources of thought for my own coding will be absolutely essential to developing my skills further. I chose this blog because I wanted to hone my skills but lack strategies to do so, and this applies beyond just testing for me.

Source:
https://www.stickyminds.com/article/repetition-practice?page=0%2C0

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.

Week 8 Blog

This week’s blog topic was chosen simply because I had zero knowledge of the term/topic. Jake Holy’s blog on Stochastic and Property-Based Testing blog covers the uses of each testing and effective tools used to implement each. Stochastic testing refers to the testing method that uses random inputs to test the behavior of the program. Rather than using predetermined inputs for test cases, stochastic utilizes various inputs to find unexpected bugs in the program. The main purpose of stochastic testing is to uncover errors through unorthodox methods. This method offers a wide testing coverage by testing all possible scenarios that might go unnoticed with traditional testing.

Property based testing refers to the method of testing by describing what the software should do rather than creating distinct test cases. Initially, testers establish properties that describes what the code should always do. This method of testing utilizes tools that automatically generate test cases to test these properties. After generating these cases, random inputs are utilized to ensure the properties are followed. The benefit of this testing method is testers are only required to declare the properties the code must follow. Instead of manually creating test cases and risking the possibility of missing a test case, these cases are generated for them. Property based testing guarantees effective test coverage. Additionally, this form of testing allows testers to focus on the abstraction and behavior of their code, allowing for a more robust product.

The blog goes in-depth with various testing tools, for example, a testing library created for the Haskell programming language called QuickCheck, which allows developers to write properties for their code which is automatically generated into test cases. QuickCheck has become a very popular tool to use for testing due to its automation, which is why it has been ported to other programming languages like Python and Scala.

The second tool that the blog mentions is Stimulant for Clojure. Similar to QuickCheck, Stimulant allows developers to define properties and it automatically generates test cases to test your program.

One thing that is mentioned in both testing libraries is shrinking. Shrinking refers to the method of finding the smallest input of a failing case, allowing developers to precisely pinpoint areas in the program that is causing the test case to fail. It is crucial that developers know their program has failed a test case, but it is even more crucial that they know why, so they can effectively fix the problem.

Blog: https://blog.jakubholy.net/2013/06/28/brief-intro-into-randomstochasticprobabilistic-testing/

From the blog CS@Worcester – Computer Science Through a Junior by Winston Luu and used with permission of the author. All other rights reserved by the author.

WEEK 8

PATH TESTING.

Path testing is an approach to testing where you can ensure that every path through a program has been executed at least once. However, testing all paths does not mean that you will find all bugs in a program. There are some steps involved in path coverage testing. Step one is code interpretation. It is important to carefully understand the code you want to test. The next step is constructing a control flow graph. It shows the nodes representing code blocks and edges for the movement of control between them. The third step is determining the paths. This entails following the control’s path from its point of entry to its point of exit while considering all potential branch outcomes. While determining paths, you’ll also consider loops, nested conditions, and recursive calls. It is important to list every route like giving each path a special name or label so you can keep track of which paths have been tested. The next step is testing case design. Create test plans for each path that has been determined, make inputs that will make the program take each path in turn. Make sure the test cases are thorough and cover all potential paths. Examine the test results to confirm all possible paths have been taken. It is important to make sure the code responds as anticipated.

Some advantages of path testing is it helps reduce redundant tests, it focuses on the logic of the programs and it is used in test case design. Some cons of using path testing is the test case increases when the code complexity is increased, it will be difficult to create a test path if the application has a high complexity of code and some test paths may skip some of the conditions in the code. There are three path testing techniques which are Control Flow Graph (CFG) – The Program is converted into Flow graphs by representing the code into nodes, regions, and edges. Decision to Decision path (D-D) – The CFG can be broken into various Decision to Decision paths and then collapsed into individual nodes. Independent (basis) paths- Independent path is a path through a DD-path graph which cannot be reproduced from other paths by other methods. I chose these two resources because they go more in depth about path testing and help explain it well. One of the sources talks about the pros and cons of using path testing, the types of path testing which I didn’t know before this.

References.

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

https://www.tutorialspoint.com/software_testing_dictionary/path_testing.htm

From the blog CS@Worcester – Site Title by lynnnsubuga and used with permission of the author. All other rights reserved by the author.

Unlocking the Power of Stubs in Software Testing


In the realm of software development, testing is a critical phase that ensures the quality and reliability of the product. This week, my exploration led me to a compelling resource that sheds light on an integral part of testing methodologies: the use of stubs. Stubs are simplified, replaceable components that mimic the behavior of real software modules, allowing testers to isolate and test individual parts of a program. The resource, an insightful article titled “A Comprehensive Guide to Stub and Mock Testing: Unveiling the Essence of Effective Software Testing” provided a comprehensive overview and practical advice that I found particularly enlightening.

The reason I selected this resource was its direct relevance to our current course material on software testing methodologies. As we delve into the complexities of ensuring software reliability, understanding the role of stubs becomes indispensable. This article not only introduces the concept but also illustrates its application with clarity and precision, making it an invaluable tool for beginners and seasoned developers alike.

Upon reading, I was struck by the depth of information presented. The article begins by defining stubs and differentiating them from other testing techniques such as mocks and drivers. It then delves into practical scenarios where stubs can significantly enhance the testing process, such as in unit testing and integration testing. The step-by-step guide on implementing stubs, complete with examples in popular programming languages, was particularly useful.

Reflecting on the content, I realized the importance of stubs in creating a controlled test environment. By simulating specific components, stubs enable testers to pinpoint errors more efficiently and focus on testing the functionality of individual units without the complexity of the entire system. This not only streamlines the testing process but also improves the accuracy of test results.

The application of what I learned from this article to my future practice is clear. I anticipate using stubs to conduct more effective and efficient testing, particularly in complex software systems where isolating components can be challenging. The hands-on examples provided will serve as a reference guide as I implement stubs in my projects.

For those interested in diving deeper into the subject, I highly recommend reading “A Comprehensive Guide to Stub and Mock Testing: Unveiling the Essence of Effective Software Testing” This resource has significantly enhanced my understanding of stubs in software testing and equipped me with practical skills that I look forward to applying in my future endeavors.

Resource Link: https://medium.com/@fideraphael/a-comprehensive-guide-to-stub-and-mock-testing-unveiling-the-essence-of-effective-software-testing-7f7817e3eab4

As we continue to explore the vast landscape of software testing, I am excited to share more discoveries and insights. Stay tuned for more reflections and learning experiences.

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.

Sprint retrospective

Our team has reflected on our recent project experiences and identified areas where we can strengthen our collaboration to improve project outcomes. Here’s a breakdown of what worked well and what didn’t, along with proposed changes for improvement:

Successes:

  • We successfully completed a significant portion (75%) of small tasks.
  • Our meetings were productive, fostering meaningful discussions.
  • Communication among team members was clear and effective.

Challenges:

  • Difficulty with Docker-compose and documentation tasks due to inaccurate task weighting.
  • Essential details were not easily accessible, often buried within overarching epics.
  • Task distribution among team members was uneven.
  • Overreliance on one team member for handling GitLab logistics.
  • Limited collaborative assistance on individual issues.

Proposed Team Improvements:

  • Foster a culture of teamwork by encouraging mutual assistance on tasks.
  • Assign task weights more accurately based on lessons learned from previous sprints.
  • Improve team proficiency with GitLab and provide support as needed.
  • Ensure that issue details are readily accessible within individual tasks.
  • Distribute task assignments more evenly among team members.

Proposed Individual Improvements:

  • Communicate problems to teammates or the professor promptly for timely resolution.

From the blog CS@Worcester – THE SOLID by isaacstephencs and used with permission of the author. All other rights reserved by the author.

Understanding Mock Objects


Understanding Mock Objects: A Journey from Confusion to Clarity

When I first stumbled upon the concept of “mock objects,” it was during my foray into the Extreme Programming (XP) community. The term has since become more prevalent, particularly among those versed in XP-influenced testing literature. Yet, mock objects are frequently misconstrued, often mixed up with stubs, which serve as basic aids in testing environments. This confusion is understandable;

Mock objects represent a nuanced divergence in the realm of software testing, embodying both a shift in test result verification—state versus behavior verification—and an ideological split in testing and design methodology: classical versus mockist Test Driven Development (TDD).

Diving into Testing Styles

To elucidate, let’s consider a straightforward example: testing an order system interacting with a warehouse. In traditional state verification tests, we’re primarily concerned with the end-state of the system under test (SUT) and its collaborators after the exercise phase. Here, both the SUT (Order) and a real collaborator (Warehouse) are employed, focusing on the system’s final state to verify test success.

Conversely, tests utilizing mock objects—like those in the jMock library—adopt behavior verification, emphasizing the interactions between the SUT and its collaborators. Instead of a real warehouse, a mock warehouse is used, setting expectations for how the SUT should behave. This approach focuses not on the final state but on ensuring the SUT makes the correct calls to its collaborators.

Exploring Classical vs. Mockist TDD

The distinction doesn’t stop at test execution. It extends into the philosophy behind the testing approach. Classical TDD practitioners utilize real objects where feasible, employing stubs or mocks primarily for cumbersome collaborators.

Mock objects are born from the XP community’s focus on TDD, where design evolves through test iterations. This “need-driven development,” particularly championed by mockists, advocates for outside-in programming, starting from the topmost user interface layer and working inwards, designing the system piece by piece.

Fixture Setup and Test Isolation

Fixture setup and test isolation further differentiate the two approaches. Classic TDD often involves extensive fixture setup, creating the SUT along with all necessary real collaborators. Mockist TDD, by contrast, requires only the SUT and its direct mock collaborators, potentially simplifying test setup

Design Implications and Personal Reflections

The decision between classic and mockist TDD extends beyond mere testing strategy; it influences design philosophy and system architecture. Mockist TDD tends to encourage more decoupled, modular designs, as each component’s interactions are explicitly defined and isolated.

As someone who initially grappled with understanding mock objects, I’ve come to appreciate their value in elucidating system behaviors and fostering thoughtful design. Yet, the choice between classical and mockist TDD ultimately depends on individual project needs, team preferences, and the specific challenges at hand.By understanding the nuances between these approaches, developers can make informed decisions that best suit their projects, fostering environments where quality software can thrive.

Based link: https://martinfowler.com/articles/mocksArentStubs.html

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

Another Look at Boundary Value Analysis and Equivalence Class Partitioning

Recently in CS443 – Software Quality Assurance and Testing we’ve been learning some of the conceptual aspects of code testing that are required to identify the relevant points of programs to test as likely break points. We’ve primarily learned about Boundary Value and Equivalence Class testing strategies, so I decided to find a blog to learn more about each of these from a third-party perspective. I landed upon a (relatively) recent blog on TestSigma – a (automatic) testing platform – from June 2023.

The post discusses the overall importance of software testing in ensuring functionality and reliability of software products focusing on the defining aspects of the two methods we’ve been learning: ‘Bound. Value Analysis’ (BVA) and ‘Equiv. Class Partitioning’ (ECP). BVA concentrates on testing the boundaries of a system to identify vulnerabilities, while ECP groups similar items into equivalence classes, helping testers target specific areas with a higher likelihood of containing bugs.

Benefits of applying BVA and ECP in software testing include improved understanding of the system, simplified test design, better test coverage, prioritization, and risk management. The applications of these techniques extend to various scenarios, such as database testing, network testing, hardware testing, time-based functionality, and UI testing. An interesting point that the article emphasizes is that BVA and ECP are often used together, providing an example of testing a form that accepts age as a number. It suggests partitioning the age range into groups for more effective testing while also considering likely break points.

Common challenges discussed to avoid when using BVA and ECP include restricting testing to input values alone, making assumptions about limits and classes, ignoring user behavior, over-relying on these techniques, and neglecting edge cases. The post concludes by comparing BVA and ECP, highlighting their differences in testing approaches and summarizing them as thought processes that enhance testers’ understanding of the system, leading to improved test coverage and strategy.

Test automation for BVA and ECP using tools like TestSigma (or other softwares) is also discussed, highlighting the potential benefits of saving time, ensuring accuracy, and achieving better test coverage. However, the decision to automate tests should be made considering the cost and benefit of automation and set-up.

Overall, this post taught me some interesting differences between BVA and ECP as well as reinforcing the benefits and basics we learned in class. One interesting aspect of this blog that I noticed in review is that it was written by author Apoorva Ram, a non-white woman in the computer science and specifically software engineering industry. This demographic represents a sparse minority in the computer science field and worth recognizing alongside their contribution with this and other blogs.

Sources:

https://testsigma.com/blog/boundary-value-analysis-and-equivalence-class-partitioning

From the blog CS@Worcester – Tech. Worth Talking About by jelbirt and used with permission of the author. All other rights reserved by the author.

Mastering Advanced Unit Testing: Test Doubles and Code Coverage for Beginners

As developers, writing robust, reliable code is a top priority. And when it comes to ensuring the quality of our codebase, unit testing plays a pivotal role. However, as we delve deeper into the realm of unit testing, we encounter advanced concepts like test doubles and code coverage, which might seem intimidating at first glance. But fear not, for in this beginner’s guide, we’ll demystify these concepts and explore why they are essential for writing high-quality code.

Understanding Test Doubles

Test doubles, also known as mocks, stubs, or fakes, are objects used in place of real dependencies in unit tests. They simulate the behavior of these dependencies, allowing us to isolate the code under test and verify its interactions with its collaborators.

For instance, imagine you’re testing a class that relies on an external API. Instead of making actual API calls, you can use a test double to mimic the API’s responses, ensuring your tests run swiftly and independently of external factors.

Test doubles help in:

  1. Isolation: By replacing real dependencies with test doubles, we can focus solely on testing the behavior of the unit under scrutiny without worrying about the intricacies of its collaborators.
  2. Speed: Since test doubles operate in-memory and don’t involve external resources, tests run faster, contributing to quicker feedback loops during development.
  3. Determinism: Test doubles allow us to create predictable test scenarios, ensuring consistent and reliable test results across different environments.

Code Coverage

Code coverage measures the proportion of a codebase that is exercised by automated tests. It provides insights into areas of code that lack sufficient test coverage, enabling developers to identify potential bugs and improve overall code quality.

While achieving 100% code coverage doesn’t guarantee bug-free software, it serves as a valuable metric for assessing the thoroughness of our test suite.

Code coverage aids in:

  1. Identifying Untested Code: It highlights parts of the codebase that lack test coverage, prompting developers to write additional tests for those areas, thus reducing the likelihood of undetected bugs.
  2. Improving Confidence: Higher code coverage instills confidence in the codebase, indicating that most critical paths and edge cases are adequately tested, thereby reducing the risk of regressions.
  3. Refactoring Safely: With comprehensive test coverage, developers can refactor code with confidence, knowing that any unintended changes are likely to be caught by existing tests.

In conclusion, mastering advanced unit testing techniques like test doubles and code coverage is crucial for any developer striving to deliver high-quality software. By leveraging test doubles, we can isolate units under test, while code coverage empowers us to assess the thoroughness of our test suite. Incorporating these practices into our development workflow not only enhances code quality but also fosters a culture of test-driven development, ultimately leading to more robust and maintainable software.

For further reading, check out this article from Christian Findlay on writing testable code and its importance in software development. Happy testing!

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

Path Testing Demystified

Hello, It’s me, your favorite computer science student ready to once again complain about the career path I chose myself.

Today’s menu of minor headaches (I’ve got to stop using this) consists of Path Testing, which is the same as checking every corner of your room for monsters before going to bed to ensure your beauty sleep doesn’t get interrupted.

Imagine you’re playing a video game where you choose paths to reach the exit of a maze. Some paths are straightforward, others are mazes with obstacles. Path testing is the same principle but with your code. You need to check every route your code can take to catch bugs hidden off the beaten path.

Think of your code as a map, with each part representing a stop or a crossroad. The goal is to explore all the stops and paths without an endless journey. We use a Control Flow Graph as a map for your code to ensure that we are not missing any hidden detours.

To implement Path Testing you only need to follow a few key steps:

  1. Create the Control Flow Graphs: This graph maps out all the possible routes through the program.
  2. Calculate Cyclomatic Complexity: This metric is the guide for the number of test cases needed for adequate coverage.
  3. Identify Independent Paths: Determine the set of paths that cover all the edges and nodes in the graph.
  4. Design Test Cases: Create test cases that will traverse each identified path.

That’s pretty much it.

Now you may say “But Ano why even bother with Path testing?”. Well, Path Testing is your code’s ultimate test drive. It uncovers sneaky bugs that hide in specific conditions and gives you a deep understanding of your code, making it easier to add features without issues.

And yet there is a catch. While Path Testing may be great, it can also be tricky for complex apps. Trying to test every path can feel like planning a road trip to Mars. The key is to smartly select which paths to test, covering as much ground as possible without getting lost in the details.

Just like our previous entry on software testing, Path Testing is another secret weapon for robust code. It’s meant to bring you peace of mind, ensuring your app or program performs without any flaws. So, before you deliver or push your code, be sure to take it on this essential road trip that guarantees your code does what it is supposed to.

Till next time,

Ano out.

References:

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

https://www.guru99.com/basis-path-testing.html

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