Category Archives: CS-443

Understanding Object-Orientated Testing

Testing In context of software development is a critical process that involves systematically checking a program or system to ensure it performs as intended. In software development, It is really important to check our work making sure everything works as it should. When we write code using object-orientated programming (OOP) which is a common way to organize and write our software, we need a special kind of checking called Object-Orientated Testing (OOT). This blog dives into what OOT is, inspired by the detailed article from GeeksforGeeks , showing why it is different and important.
Summary of the resource

The article from GeeksforGeeks explains how testing for Object-Orientated programming is different than traditional testing. OOP deals with concepts like classes and objects (which are basically groups of functions and data that model real-world things). OOT then focuses on checking these classes and objects, along with how they interact with each other, which is not something you do in traditional testing. The article talks about the challenges of doing OOT, like making sure objects work well together and the need for different tools and strategies to do it right.

Reason for selection

I picked this article because it does a great job of showing how checking object-orientated code is different from the usual way of testing code. It fits well with what we are learning in class about how to build software, giving us a clear picture of how to make sure out OOP projects work well

Reflection:

Reading about OOT made me realize that checking our code in OOP needs more than just looking at each part by itself. We need to see how all parts work together. It was an eye-opener to learn about the different tools we can use for OOT and how it helps us find and fix problems early on.

Looking forward

This article made me more aware of how important it is to use OOT in my future projects. Knowing how to do this kinds of testing means I can make sure my software is solid and works well, which is very important for any software developer.

Conclusion

Object-Orientated Testing is a key skill for software developers, especially as we build more complex and interconnected software. The insights from the GeeksforGeeks article highlights the unique aspect of OOT and remind us why adapting our testing to match our coding style is crucial. As we tackle bigger projects keeping these OOT principles in mind will help us build better and more reliable software

From the blog CS@Worcester – Josies Notes by josielrivas and used with permission of the author. All other rights reserved by the author.

Blog Post 1- CS443

For this weeks blog post I read the article on Testsigma’s Website called “Unit Testing | What it is, How it Works, Types & Top Benefits” by Diane Wong. It talks about the significance of unit testing in software development, giving a full overview of its benefits and best practices. Unit testing is an important feature of the software testing process, involving the testing of individual units or components of a software application in isolation. The main goal that I though was shown in this blog post was to show that each unit has functions as show and how unit testing can contribute to the overall reliability and robustness of the entire software system. The article highlights the key advantages of unit testing, pointing out its role in spotting and fixing bugs early in the development cycle. This is usually done by dividing and testing individual units and this helps the developers quickly pinpoint and address issues and reducing the chances of more complex and costly problems later in the development process. The blog post also discusses the importance of unit testing and how critical it is in the process. Also, the article explains the best practices for effective unit testing, including the using of testing frameworks, test coverage metrics, and the adoption of a test-driven development (TDD) methods. It emphasizes the integration of unit testing into the overall software development lifecycle. In conclusion, the blog post from Testsigma provides a full and informative guide to unit testing it highlights its importance in software development and offering practical insights into its implementation and best practices. This was a helpful blog post to read, since it helped me grasp the information about Unit Testing since it was something we have worked on in the beginning of the semester, it helped it stay fresh in my mind as we learn other wats of testing this semester.

From the blog CS@Worcester – CS- Raquel Penha by raqpenha and used with permission of the author. All other rights reserved by the author.

Mastering Unit Testing: A Developer’s Guide to Enhancing Code Quality (Week – 9)

Unit testing is an integral part of software development, crucial for validating individual code segments’ functionality. This systematic approach helps in identifying defects early, enhancing code reliability, and simplifying modifications. Let’s delve into the nuanced strategies of unit testing, including specification-based and code-based techniques, and explore the role of code coverage and the utility of JUnit in ensuring robust software solutions.

Specification-Based Testing Techniques

In the realm of specification-based or black-box testing, the focus is on assessing the software’s external behavior rather than its internal structure:

  1. Boundary Value Testing: This method targets the extreme ends of input ranges, where most errors tend to occur. By testing these boundary values, developers can identify potential edge case issues that might not emerge under normal test conditions.
  2. Equivalence Class Testing: This strategy simplifies testing by grouping inputs into classes that elicit similar behaviors. Testing one sample from each class can reduce the number of tests while maintaining effectiveness, ensuring that different scenarios are adequately represented.
  3. Decision Table-Based Testing: For functions governed by complex rules, decision table-based testing offers a structured approach. It maps different input combinations to their expected outcomes, ensuring all logical branches are explored and validated.

Code-Based Testing Strategies

Code-based or white-box testing requires an understanding of the software’s internal workings:

  1. Path Testing: Essential for ensuring every executable path is tested at least once, path testing uncovers sections of code that could be prone to errors, enhancing the overall robustness of the application.
  2. Data Flow Testing: Focusing on the lifecycle of data, this method tracks the creation, manipulation, and usage of variables. It’s particularly effective in identifying issues related to improper data handling and scope errors.

Emphasizing Code Coverage

Code coverage metrics are crucial for gauging the extent of tested code. While high code coverage does not eliminate all software bugs, it indicates thorough testing and contributes to higher quality code. Achieving substantial code coverage helps in maintaining and updating code with confidence.

Leveraging JUnit for Java Testing

JUnit, a cornerstone in the Java programming ecosystem, streamlines the creation, execution, and documentation of unit tests. It supports annotations for defining test cases and employs assertions to verify code behavior, aligning with Test-Driven Development (TDD) practices. JUnit’s simplicity aids in regular test implementation, encouraging developers to maintain code quality continuously.

In conclusion, unit testing is not just a task but a discipline that significantly impacts software quality. By integrating specification-based and code-based testing methods and striving for extensive code coverage, developers can craft more reliable, maintainable software. JUnit further simplifies the testing process, embedding quality into the development lifecycle. For a comprehensive guide to unit testing with JUnit, refer to “JUnit in Action, Third Edition” by Catalin Tudose, a resource that offers deep insights and practical examples for effective Java testing.

By embracing these practices, developers can ensure that their code not only functions as intended but also adapts gracefully to future changes and requirements.

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

Week 9: CS-443

Static vs Dynamic Testing

Testing software and ensuring it works as intended is a crucial part of software development. Two approaches to testing are static and dynamic. Static testing involves testing the software without running the code, while dynamic executes the program and tests its behavior in various situations.

Static Testing

The term static testing comes from examining the code in a “static” state rather than actually running it. Because the code is never actually executed with static testing, the focus of testing is on analyzing the software’s documentation along with the design of the code, and the code itself. Static testing is most beneficial in the early stages of development. Since the code is never being executed, a fully working implementation is not required unlike dynamic testing. Issues identified early in development are easier and less costly to fix resulting in better maintainability, and decreased time and money spent in the long term. Some static testing techniques include informal reviews, walkthroughs, static code reviews, and more.

Dynamic Testing

Dynamic testing involves actually executing the software and testing its behavior based on various inputs. Test cases are created to conduct test runs to identify defects and ensure the software meets the required specifications. Along with testing the software with various inputs and comparing to the expected outputs, error conditions are also tested. Error conditions are inputs that are outside of the valid input range, and the software should be able to handle the invalid input without any unexpected behavior. Dynamic testing is performed after coding and development are complete, whereas static testing usually begins in the early stages of development. Because dynamic testing executes the code, the software must be far enough in development where the software functions, performs, and secure as intended. Those reasons are why dynamic testing is to be completed after development. Some dynamic testing techniques include unit testing, integration testing, and system testing.

Conclusion

This article was chosen because it clearly explained what static and dynamic testing are and the differences between them. The article was also easy to follow along. I enjoyed learning about when static and dynamic testing are most beneficial because I was unaware that static testing begins in the earlier stages of development while dynamic is performed after development. So far in my software development journey, I have not written many tests for the code I have written, and have mainly done manual testing which takes extra time and may have errors. Gaining insight in these techniques will be helpful when testing code in the future.

Resource:

https://www.guru99.com/static-dynamic-testing.html

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.

Test-driven development using mocking and stubbing

In the world of software development, ensuring that your application works as intended is crucial. This is where testing comes into play, serving as a safeguard against unexpected behavior and bugs. But how do you test effectively? This is where concepts like mocking, stubbing, and contract testing become vital. Let’s dive into these techniques and see how they can enhance your testing strategy.

  • The Essence of Mocking and Stubbing

Mocking and stubbing are techniques used primarily in unit and component tests, but their usefulness extends beyond these. They are about creating fake versions of external or internal services to streamline and stabilize testing processes.

Mocking refers to creating a faux version of an external or internal service to replace the real one during testing. This is especially useful when your code interacts with object properties rather than behaviors. By mocking dependencies, you enable your tests to run more quickly and reliably since they are not bogged down by real-time data fetching or complex logic processing.

On the other hand, stubbing involves creating a stand-in for certain behaviors of an object rather than the entire object. This technique is useful when your implementation interacts only with specific behaviors of an object, enabling faster and more focused tests.

  • Practical Applications

When your code uses external dependencies, such as system calls or database access, mocking or stubbing comes in handy. For example, instead of actually creating or deleting a file during a test, you can mock or stub the file system’s responses. This not only speeds up the testing process but also ensures that your tests remain independent and easy to manage.

  • Contract Testing in Microservices

In a micro-services architecture, services interact based on predefined “contracts” detailing expected requests and responses. Contract testing verifies that these interactions meet the agreed-upon standards. Unlike traditional integration testing, contract testing focuses on the interfaces between services, making it a leaner and more targeted approach.

This type of testing is beneficial for checking the integrity and reliability of service interactions without deploying an entire system. It’s particularly effective in continuous integration pipelines, as it ensures that changes in one service don’t break the contract with another.

  • The Role of Mocks and Stubs

In contract testing, mocks and stubs play a crucial role. By simulating the services that an application interacts with, developers can check the consistency and reliability of the application’s responses without relying on live services. This approach significantly reduces testing time and increases reliability.

  • Conclusion

Testing is an integral part of the software development lifecycle, and techniques like mocking, stubbing, and contract testing are essential tools in a developer’s arsenal. By understanding and implementing these strategies, we can ensure that your tests are both efficient and effective, leading to more reliable and maintainable software.

The link to the initial blog post: https://circleci.com/blog/how-to-test-software-part-i-mocking-stubbing-and-contract-testing/

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

Object Oriented Testing

https://www.javatpoint.com/difference-between-object-oriented-testing-and-conventional-testing#:~:text=In%20object%2Doriented%20testing%2C%20the,encounter%20in%20the%20real%20world.

Object Oriented testing focuses on the behavior of an object or class within an  object oriented system with its goal being to ensure any interaction or expected behaviors are correctly carried out when the system is used. This type of testing also heavily relies on ‘real world’ situations for example when writing test cases you would base your cases on things that the system is likely to interact with in the real world input wise which makes it easier to identify any possible behavioral issues within the system. There are three different testing phases which are commonly used in object oriented programming which are Unit testing, integration testing and system testing. Unit testing is used when testing classes or objects while isolated from the rest of the software, integration testing is used to verify that objects or classes are able to properly work together and system testing is used when testing an entire system to verify that the system itself works properly. Object oriented testing also requires the tester to have knowledge of a system’s inner workings in order to properly test it. This type of testing obviously is used on object oriented software which would be any software that is written using an object oriented language so in that aspect it is limited as object oriented testing would not be relevant or necessary to software which is not in the object oriented domain.

I found this article useful as it gets straight to the point when it comes to outlining the basic idea behind object oriented testing but it also chooses to compare it to conventional testing which helps the reader to differentiate between some of the different attributes of the two testing types as well as some of their similarities. This really helps when it comes to understanding why object oriented testing is defined as its own type of testing when their are already many other testing methods. This article helped me gain a greater understanding of object oriented testing which will help me to think more in depth about the cases I am able to write while testing in the future. The specific use of real world scenarios mentioned in this article was particularly interesting to me as I had not previously thought about how using real scenarios would typically provide more accurate results and or errors as compared to randomly selected scenarios which will also influence how I write test cases in the future.

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

Static vs. Dynamic Testing

This week I decided to touch on static and dynamic testing. I wanted to find a blog that talks about different techniques for each type of testing. While searching I found the blog Static Testing VS Dynamic Testing – Key Differences testing by Kiruthika Devaraj. It first begins by generally defining the two types of testing. Devaraj first defines static testing as involving testing the software without running it” and dynamic testing as involving “executing the program and testing its behavior in different scenarios”. They then go on to explicitly outline the differences in the next section. 

In the section titled “Differences Between Static Testing and Dynamic Testing”, they explain that static testing involves reviewing the documentation, design or code to check for defects and errors without executing the software. They also mention that this type of testing aims to identify issues early in software development when they are easier and less expensive to fix. They explained that dynamic testing involves executing the software and testing its behavior in different scenarios. They explain that during this process testers create test cases and run tests to identify defects and ensure the software meets the specified requirements. By testing the program against a variety of inputs, expected outputs, and error scenarios, this kind of testing essentially tries to evaluate the product’s functionality, performance, and security and ensure that it operates as predicted. In this section, the author uses bullet points and spacing to organize the information and make it easier to digest. 

The next section is a table that clearly outlines the differences in features like definitions, objectives, types of testing, timing, and results for static and dynamic testing. Static testing involves code review, walk-through, and inspection while the other involves unit, integration, system, acceptance, performance, security, and user acceptance testing. The author then explains how to choose between the two types of testing. They mention that it comes down to the specific requirements, objectives of the testing process, and desired outcomes. I enjoyed this article because the author got straight to the point when writing the article while clearly defining the use of each type of testing. I think the way they went about writing this informational piece was effective in keeping the reader’s attention by outlining the information in the simplest way possible. The use of bullet points and tables helped me to remember the information better. I am likely going to have to test my future personal projects so knowing the differences between the two types of testing and how to choose it was important to read about.

From the blog CS@Worcester – Live Laugh Code by Shamarah Ramirez and used with permission of the author. All other rights reserved by the author.

Week 8 blog Post

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

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

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

https://hinchman-amanda.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.