In the realm of software development, testing is an integral part of the development cycle. It ensures that the code behaves as expected under various conditions and scenarios. Test doubles are a crucial concept in testing, especially in unit testing, where dependencies need to be isolated to ensure focused and reliable tests.

Test doubles are objects used in place of real dependencies during testing. They help in simulating the behavior of real objects and controlling the environment of the test, making it easier to isolate the component being tested. There are several types of test doubles, each serving a specific purpose in testing. Let’s delve into some of the most common ones:

1. Dummy Objects: Dummy objects are the simplest form of test doubles. They are typically used when an object is required as a parameter but is not actually used within the test. Dummy objects do nothing and are only present to fulfill the method signature or parameter requirements.
2. Stub Objects: Stub objects provide predetermined responses to method calls during testing. They are used to simulate specific behavior of dependencies, returning fixed values or predefined responses to method calls. Stubs are useful when testing code that relies on external services or complex dependencies that are not easily controllable.
3. Mock Objects: Mock objects are more sophisticated than stubs. They record and verify interactions with the test subject, allowing expectations to be set on method calls. Mocks are useful for verifying that certain methods are called with specific parameters or in a certain sequence. They help in ensuring that the code under test behaves as expected in terms of interactions with its dependencies.
4. Fake Objects: Fake objects are implementations that mimic the behavior of real objects but are simpler and faster. They are often used to replace complex or slow dependencies with lightweight alternatives during testing. Fakes are particularly useful when dealing with external systems or resources that are difficult to control or reproduce in a testing environment.
5. Spy Objects: Spy objects are similar to mocks but with additional functionality. They record the interactions with the test subject like mocks, but they also allow access to the recorded data for verification or further processing. Spies are beneficial when you need to inspect the behavior of the code under test along with its interactions with dependencies.

Understanding the different types of test doubles empowers developers to write effective and efficient tests. By leveraging test doubles appropriately, developers can isolate components, control dependencies, and ensure reliable and maintainable tests.

For more in-depth information on test doubles and their usage, you can visit Martin Fowler’s article on Test Doubles. Martin Fowler is a renowned software developer and author known for his expertise in software design and development practices. His article provides comprehensive insights into various aspects of test doubles and their role in software testing.

In conclusion, mastering the use of test doubles is essential for writing robust and reliable tests, ultimately leading to higher-quality software products. Whether you’re dealing with simple dummy objects or complex mock objects, understanding when and how to employ each type of test double is key to effective testing practices in programming.

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

Breakable Toys is a pattern that shows the importance of learning through failure and trail and error in software development. It teaches that failure is inevitable in the learning process and encourages developers to create small,  projects where they can make mistakes without breaking something permanently . By building a toy systems with similar toolsets to their professional projects but on a smaller scale developers can push their abilities to the limit and gain experience. The pattern suggests building simple projects like wikis, calendars, or address books. These projects serve as opportunities to try out new ideas and techniques without the pressure of real-world consequences in a job scenario . They allow developers to learn from their mistakes, iterate, and grow as professionals. Examples of Breakable Toys include personal wikis, games like Tetris or Tic-Tac-Toe, blogging software, and IRC clients. The idea is to choose projects that are relevant and useful to the developer’s life, allowing them to invest time and effort into exploring different aspects of software development. The pattern also emphasizes the importance of enjoying the process of building these toys. If the projects become stressful, they are less likely to be learning experiences that are successful.Also , developers should be open to the possibility that their toys may evolve into something more significant or even gain other users over time. A classic example cited is Linus Torvalds’s creation of Linux, initially announced as a hobby project to build a small operating system similar to Minix. This shows how even the most significant projects can start as personal experiments or Breakable Toys. Overall, Breakable Toys encourage developers to embrace failure, take risks, and continuously seek opportunities for learning and growth in their craft. By building and iterating on these small projects, developers can expand their skill sets, deepen their understanding of tools and technologies, and ultimately become more proficient practitioners of software development. I have used breakable toys for a school setting but never for just for fun, after diving more to the pattern I will be deepening during my free time. 

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

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.

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.

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.

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.

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.

Beginning a journey in the Software Development field is like walking through a maze. Every turn presents different challenges, different opportunities, and different outcomes. Having a mentor can be the guiding light that we need through our journeys. The Finding Mentors pattern underscores the importance of seeking out help and assistance from experienced individuals who can provide both support and guidance while navigating the complexities of the field.

Reflecting on my own experiences, having a mentor can have quite a profound impact on shaping skills, gaining knowledge, and viewing things from different perspectives. I’m yet to experience this within my software development journey, but experienced it on numerous occasions with my athletic career where I was coached by a number of professional athletes. This in turn enhanced my skills and knowledge and resulted in me becoming a better overall player and athlete. I would assume the same would happen within the development field. Having a mentor would overall increase our knowledge and skillset, allowing us to further walk down our professional journeys.

What I found particularly interesting about this pattern was the emphasis on the give and take nature of mentorship. While apprentices seek guidance from experienced individuals, they then also have the opportunity to mentor others. This creates a culture of continuous learning and collaboration within the software development community as a whole. Additionally, the pattern has reinforced the notion that mastery can be achieved through the guidance and mentorship of individuals who have already walked the path we are trying to take. This allows us to take a step further in our learning journey. Therefore, this has prompted me to actively seek out mentors and engage more proactively within the development community to accelerate my personal learning and growth.

Additionally, while having a mentor can be an extreme plus in our own personal development, we should acknowledge that finding mentors can be challenging. This is due to the fact that some individuals may lack access to established networks or communities. In this case, we can look into alternative approaches to finding a mentor through online platforms or peer-to-peer mentorship programs.

Therefore, the Finding Mentors pattern can serve as a guiding light for us as aspiring craftsman, utilizing the power of mentorship in our professional development. By embracing the core message outlined within the pattern and seeking out mentorship opportunities, apprentices can then navigate through the complexities of software development with purpose and confidence, while also growing and learning for their professional career.

From the blog CS@Worcester – Conner Moniz Blog by connermoniz1 and used with permission of the author. All other rights reserved by the author.

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.