The main idea of the article is that mocking lets you replace real dependencies with controlled ones. Instead of using a real database or API, you create a mock version that returns specific values. This allows you to test a piece of code on its own without depending on other parts of the system. The goal is to isolate the code you are testing so you know exactly where a problem is coming from.

That idea stood out to me because it changes how I think about testing. Before this, I mostly thought about testing as running the whole program and checking if the output was correct. Mocking shows that testing is not always about the full system. Sometimes it is better to focus on one part at a time and control everything around it.

The article also explains that mocking helps make tests faster and more reliable. If you depend on real systems like APIs, your tests can fail for reasons that are not related to your code. For example, a network issue could cause a test to fail even if your logic is correct. With mocking, you avoid that by using predictable responses. That makes tests more consistent and easier to trust.

I chose this article because it directly connects to what we have been working on in class. Mocking was one of the harder concepts to understand at first, so seeing it explained in a simple way helped reinforce the idea. It also made it clearer why we use mocking instead of always testing with real objects.

What I take from this is a better understanding of how to approach testing. Instead of always testing everything together, I should think about isolating parts of the code. If something depends on an external system, I can mock it and focus on the logic I want to test. This makes the testing process more controlled and easier to manage.

Going forward, I expect to use mocking when I am testing code that depends on APIs or databases. It gives me a way to test my code without needing everything else to be working. More importantly, it helps me write tests that are focused and reliable.

Source: https://testrigor.com/blog/what-is-mock-testing/

From the blog CS@Worcester – Harley Philippe's Tech Journal by Harley Philippe and used with permission of the author. All other rights reserved by the author.

I chose this particular resource because I wanted something that explained the difference in a practical way instead of just defining the terms. A lot of testing concepts sound simple at first, but they become much more meaningful when they are tied to real software development decisions. This blog post stood out because it compares the two approaches clearly and in a way that is easy to apply. It also helped me see that specification-based testing is useful when the goal is to check whether the software meets the requirements, while code-based testing is useful when the goal is to examine the internal logic and catch problems that might not be visible from the outside. That contrast is exactly why I selected it; it directly supports the course material and gives a straightforward example of how testing can be approached from two different perspectives.

Good testing is not just about choosing one method and ignoring the other. Before reading this blog, I tended to think that one style might be better than the other, or that the very least you could probably get away with doing just one or the other. However, now I understand that they solve different problems. Specification-based testing reminds me to think about what the user is supposed to experience, while code-based testing is more to think about how the program is actually built. That balance matters because software can still fail even if it looks correct from one angle. I realize now that checking only the code or only the requirements is not enough. Moving forward I expect to apply both ideas by first making sure the software behaves the way it should and then looking deeper to see whether the internal logic supports that behavior correctly.

From the blog Joshua's Blog by Joshua D. and used with permission of the author. All other rights reserved by the author.

I chose this particular resource because I wanted something that explained the difference in a practical way instead of just defining the terms. A lot of testing concepts sound simple at first, but they become much more meaningful when they are tied to real software development decisions. This blog post stood out because it compares the two approaches clearly and in a way that is easy to apply. It also helped me see that specification-based testing is useful when the goal is to check whether the software meets the requirements, while code-based testing is useful when the goal is to examine the internal logic and catch problems that might not be visible from the outside. That contrast is exactly why I selected it; it directly supports the course material and gives a straightforward example of how testing can be approached from two different perspectives.

Good testing is not just about choosing one method and ignoring the other. Before reading this blog, I tended to think that one style might be better than the other, or that the very least you could probably get away with doing just one or the other. However, now I understand that they solve different problems. Specification-based testing reminds me to think about what the user is supposed to experience, while code-based testing is more to think about how the program is actually built. That balance matters because software can still fail even if it looks correct from one angle. I realize now that checking only the code or only the requirements is not enough. Moving forward I expect to apply both ideas by first making sure the software behaves the way it should and then looking deeper to see whether the internal logic supports that behavior correctly.

From the blog Joshua's Blog by Joshua D. and used with permission of the author. All other rights reserved by the author.

I chose this particular resource because I wanted something that explained the difference in a practical way instead of just defining the terms. A lot of testing concepts sound simple at first, but they become much more meaningful when they are tied to real software development decisions. This blog post stood out because it compares the two approaches clearly and in a way that is easy to apply. It also helped me see that specification-based testing is useful when the goal is to check whether the software meets the requirements, while code-based testing is useful when the goal is to examine the internal logic and catch problems that might not be visible from the outside. That contrast is exactly why I selected it; it directly supports the course material and gives a straightforward example of how testing can be approached from two different perspectives.

Good testing is not just about choosing one method and ignoring the other. Before reading this blog, I tended to think that one style might be better than the other, or that the very least you could probably get away with doing just one or the other. However, now I understand that they solve different problems. Specification-based testing reminds me to think about what the user is supposed to experience, while code-based testing is more to think about how the program is actually built. That balance matters because software can still fail even if it looks correct from one angle. I realize now that checking only the code or only the requirements is not enough. Moving forward I expect to apply both ideas by first making sure the software behaves the way it should and then looking deeper to see whether the internal logic supports that behavior correctly.

From the blog Joshua's Blog by Joshua D. and used with permission of the author. All other rights reserved by the author.

There are many types of testing in software, but there are three key approaches every software developer should know and that is black box, white box, and gray box testing. By having a basic understanding of these three testing approaches, will help you test and debug more efficiently. Before we can continue, we must define and come to a shared consensus of what they are.

Black box testing is testing functionality without code knowledge. Furthermore, the tester does not have internal access to code. The result of this is that they cannot see code structure, design, and implementation. From this, black box testing becomes all about testing and validating user workflow such as inputs, outputs, interfaces, APIs, etc. In essence, it checks the overall system’s behavior.

On the other hand, white box testing deals with when the tester has access to the internal code, but not functionality. The primary purpose of this type of testing is to validate internal operations done by testing functions, loops, methods, etc. It’s very important that when utilizing white box testing, the tester has greater knowledge of both the code and expected logic. The outcome of this is to ensure efficiency, security, and accuracy.  

Gray box testing combines the two testing methods listed above. Now with functionality and partial code knowledge, this enables the tester(s) to have more enhanced testing, thus leading to stronger and deeper detections of bugs and logic issues. 

Although they were discussed in defining them above, here are the key benefits of these software testing approaches:

1. Ensures software quality
2. Detects defects early
3. Improves test coverage
4. Enhances security and performance
5. Supports manual and automated testing

By implementing these testing approaches your system will improve drastically, rather than not implementing these. 

I felt like I should revisit these concepts and to further reinforce what I’ve learned and also create a learning opportunity for something I did not know.  Furthermore, gray box testing is often used in penetration testing and API testing. Additionally, when dealing with gray box testing, it requires both functional testers and developers for the highest effectiveness; not simply done by one person. 

Along with this, I feel like I have gained a better understanding of each of them as a whole/individually and when to use them. Going further, I plan to make myself more conscious of the testing approaches I am using, which will sharpen my testing skills overall.

From the blog CS@Worcester – Programming with Santiago by Santiago Donadio and used with permission of the author. All other rights reserved by the author.

The article “Decision Table Testing” from Guru99 was my choice for this blog entry because Decision Tables were a recent topic covered in class that I am trying to gain a better understanding of how they apply in the real world of Software Testing.

The article outlines a black box testing technique called Decision Table Testing. This form of testing organizes complex business rules into an easy-to-understand table format. This is accomplished by arranging both conditions (inputs) and actions (outputs) into one table, which allows the tester to identify all possible combinations of inputs. This will also make sure that all combinations or scenarios are tested. The article demonstrates how Decision Table Testing is beneficial when multiple conditions interact with one another, as this will avoid missing critical test cases. The article also provides examples illustrating how to construct a Decision Table, as well as examples of how to derive test cases from Decision Tables.

I selected this article because although I had an understanding of Decision Tables in class, my difficulty was applying Decision Tables to scenarios with problems, such as the most recent homework assignment. This resource directly relates to our course work because of the decision tables created and used to derive test cases. This article allowed me to see additional examples to help me repoint that decision tables will improve test coverage and simplify complex logic.

Think about it… You are forced to think about all combinations of conditions when using them (as opposed to carelessly selecting out test cases), therefore, having gathered sufficient data using decision tables may help to ensure that you do not leave out corner cases on projects because they did not follow a systematic mapping of everything.

The more I realize it, using decision tables will definitely impact future professional efforts. Where requirements exist, such as input validation or defining a set of business rules, decision tables WILL help organize my thoughts before drafting test cases. By doing so, it will improve the quality of my testing and enable me to communicate more easily and effectively with the rest of my future team.

Overall, I gained an in-depth understanding of decision tables for testing purposes through this resource. The ultimate benefit of decision tables is that they provide an expected level of efficiency and quality in software testing!!

Resource Link: https://www.guru99.com/decision-table-testing.html

From the blog CS@Worcester – function & form by Nathan Bui and used with permission of the author. All other rights reserved by the author.

This method of software testing is used for testing parts of code that rely on other parts of your code by replacing the dependencies with a lightweight duplicated that acts the way the tester wants it to. There are 3 main types of these Testing Doubles: Mocks, Stubs, and Fakes.

Mocks are used to replace some external interface, whether that be a class or something else. The video brings up an example of trying to test a function that calls a function that connects to some external network endpoint. If we were using Mock Testing, we would create a Mock function for the connection function in the overall function we want to test. This mock would be basically a replica of the function, but it should have essentially no functionality, meaning it shouldn’t connect to any database or anything like that. I like to think that stubs are the most hollow object or function of the 3 mentioned here, as they do not have any functionality, but instead mock the calling of the function or creation of the object.

Stubs are used to replace some external interface with predefined values. In Stub Testing, you want to test the values of your either function’s return or object’s members. Stubs are predetermined to have certain values at the point of given Unit Test’s initialization. This is done to simulate having an actual object. If we go back to the network endpoint example, instead of the function doing nothing, we have the function return a fixed value, or act in a certain way to return a fixed value.

Fakes are the closest to the actual implementation you wish to use. Fakes are essentially almost fully functional objects or functions that simulate the work in a lightweight way. Going back to the network example, you can think of the Fake for this function as actually connecting to some endpoint, but it will be not the production-ready version, only some simulate/developer one.

I do see my self using this method in my own projects going forward, especially projects with multiple people working on it. Though I don’t often do that, I do see using Test Doubles as a way to modularization testing better and to get things up and running more easily in a group setting.

In future I do want to add these types of testing in some capacity to lengthier projects, especially more disconnected projects like a website or server network or something like that.

-Mordecai

From the blog CS@Worcester – The Devlog by Mordecai Yiadom and used with permission of the author. All other rights reserved by the author.

The blog post I selected is “Understanding
Test Doubles – Fakes, Stubs, Mocks, and Spies” by Sarah Dutkiewicz. I chose
this resource because it gives our view of how we do test doubles with better examples
for class as it explains several kinds of test doubles and shows how each one
supports more focused and maintainable tests through concrete code examples. The
article explains that “test doubles” is an umbrella term for objects that
replace real dependencies during testing, and that not all doubles should be
used in the same way. The post explains that fakes are simple working
implementations made for testing, stubs return pre-programmed responses, mocks
are used to verify that certain interactions happened, and spies record calls
so the test can inspect them later. It continues to uses small C# examples with
interfaces like IUserRepository and IExternalService to show when each type is
appropriate and why choosing the right one matters. It also emphasizes that
using the wrong kind of test double can make tests harder to understand and
maintain.

             I selected this article because I needed
another view of test doubles from the other source to better understand the concept
more than I learned from class. Even though we did this in class while trying
to write with on live, it was still difficult to clearly understand when to use
each one. Seeing the concepts explained again with different examples helped me
connect the definitions to real situations in code. It showed me that choosing
the correct test double depends on the goal of the test, not just the
definition of the term as it seems like the words and definitions from examples
from class was making it harder for me to understand the concept. Also using stubs
make it easier to test the functions of the code as they are used when you only
need to control the output of a method. However, it also made me realize that
if I overuse the methods, especially mocks, it will complicate the test more
than needed especially when the goal of the test is to check the output. In the
future, I expect to apply this by thinking more carefully about whether I need
to verify interactions or simply control behavior, which will help me write
cleaner and more maintainable test cases as I can double check if the workflow
is working while in the middle of writing new lines of code.

https://blog.nimblepros.com/blogs/understanding-test-doubles/

From the blog Sung Jin's CS Devlopemnt Blog by Unknown and used with permission of the author. All other rights reserved by the author.

The blog post I selected is “Understanding
Test Doubles – Fakes, Stubs, Mocks, and Spies” by Sarah Dutkiewicz. I chose
this resource because it gives our view of how we do test doubles with better examples
for class as it explains several kinds of test doubles and shows how each one
supports more focused and maintainable tests through concrete code examples. The
article explains that “test doubles” is an umbrella term for objects that
replace real dependencies during testing, and that not all doubles should be
used in the same way. The post explains that fakes are simple working
implementations made for testing, stubs return pre-programmed responses, mocks
are used to verify that certain interactions happened, and spies record calls
so the test can inspect them later. It continues to uses small C# examples with
interfaces like IUserRepository and IExternalService to show when each type is
appropriate and why choosing the right one matters. It also emphasizes that
using the wrong kind of test double can make tests harder to understand and
maintain.

             I selected this article because I needed
another view of test doubles from the other source to better understand the concept
more than I learned from class. Even though we did this in class while trying
to write with on live, it was still difficult to clearly understand when to use
each one. Seeing the concepts explained again with different examples helped me
connect the definitions to real situations in code. It showed me that choosing
the correct test double depends on the goal of the test, not just the
definition of the term as it seems like the words and definitions from examples
from class was making it harder for me to understand the concept. Also using stubs
make it easier to test the functions of the code as they are used when you only
need to control the output of a method. However, it also made me realize that
if I overuse the methods, especially mocks, it will complicate the test more
than needed especially when the goal of the test is to check the output. In the
future, I expect to apply this by thinking more carefully about whether I need
to verify interactions or simply control behavior, which will help me write
cleaner and more maintainable test cases as I can double check if the workflow
is working while in the middle of writing new lines of code.

https://blog.nimblepros.com/blogs/understanding-test-doubles/

From the blog Sung Jin's CS Devlopemnt Blog by Unknown and used with permission of the author. All other rights reserved by the author.

The blog post I selected is “Understanding
Test Doubles – Fakes, Stubs, Mocks, and Spies” by Sarah Dutkiewicz. I chose
this resource because it gives our view of how we do test doubles with better examples
for class as it explains several kinds of test doubles and shows how each one
supports more focused and maintainable tests through concrete code examples. The
article explains that “test doubles” is an umbrella term for objects that
replace real dependencies during testing, and that not all doubles should be
used in the same way. The post explains that fakes are simple working
implementations made for testing, stubs return pre-programmed responses, mocks
are used to verify that certain interactions happened, and spies record calls
so the test can inspect them later. It continues to uses small C# examples with
interfaces like IUserRepository and IExternalService to show when each type is
appropriate and why choosing the right one matters. It also emphasizes that
using the wrong kind of test double can make tests harder to understand and
maintain.

             I selected this article because I needed
another view of test doubles from the other source to better understand the concept
more than I learned from class. Even though we did this in class while trying
to write with on live, it was still difficult to clearly understand when to use
each one. Seeing the concepts explained again with different examples helped me
connect the definitions to real situations in code. It showed me that choosing
the correct test double depends on the goal of the test, not just the
definition of the term as it seems like the words and definitions from examples
from class was making it harder for me to understand the concept. Also using stubs
make it easier to test the functions of the code as they are used when you only
need to control the output of a method. However, it also made me realize that
if I overuse the methods, especially mocks, it will complicate the test more
than needed especially when the goal of the test is to check the output. In the
future, I expect to apply this by thinking more carefully about whether I need
to verify interactions or simply control behavior, which will help me write
cleaner and more maintainable test cases as I can double check if the workflow
is working while in the middle of writing new lines of code.

https://blog.nimblepros.com/blogs/understanding-test-doubles/

From the blog Sung Jin's CS Devlopemnt Blog by Unknown and used with permission of the author. All other rights reserved by the author.