When developing robust software systems, ensuring reliable and efficient testing is paramount. Yet, testing can become challenging when the System Under Test (SUT) depends on components that are unavailable, slow, or impractical to use in the testing environment. Enter Test Doubles—a practical solution to streamline testing and simulate dependent components.

What are Test Doubles? In essence, Test Doubles are placeholders or “stand-ins” that replace real components (known as Depended-On Components, or DOCs) during tests. Much like a stunt double in a movie scene, Test Doubles emulate the behavior of the real components, enabling the SUT to function seamlessly while providing better control and visibility during testing.

The implementation of Test Doubles is tailored to the specific needs of a test. Rather than perfectly mimicking the DOC, they replicate its interface and critical functionalities required by the test. By doing so, Test Doubles make “impossible” tests feasible and expedite testing cycles.

Key Variations of Test Doubles Test Doubles come in several forms, each designed to address distinct testing challenges:

1. Test Stub: Facilitates control of the SUT’s indirect inputs, enabling tests to explore paths that might not otherwise occur.
2. Test Spy: Combines Stub functionality with the ability to record and verify outputs from the SUT for later evaluation.
3. Mock Object: Focuses on output verification by setting expectations for the SUT’s interactions and validating them during the test.
4. Fake Object: Offers simplified functionality compared to the real DOC, often used when the DOC is unavailable or unsuitable for the test environment.
5. Dummy Object: Provides placeholder objects when the test or SUT does not require the DOC’s functionality.

When to Use Test Doubles Test Doubles are particularly valuable when:

• Testing requirements exceed the capabilities of the real DOC.
• Test execution is hindered by slow or inaccessible components.
• Greater control over the test environment is necessary to assess specific scenarios.

That said, it’s crucial to balance the use of Test Doubles. Excessive reliance on them may lead to “Fragile Tests” that lack robustness and diverge from production environments. Therefore, teams should complement Test Doubles with at least one test using real DOCs to ensure alignment with production configurations.

Conclusion Test Doubles are indispensable tools for efficient and effective software testing. By offering flexibility and enhancing control, they empower developers to navigate complex testing scenarios with ease. However, judicious use is key, striking the right balance ensures tests remain meaningful and closely aligned with real-world conditions.

This information comes from this article:
Test Double at XUnitPatterns.com

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

One of the most significant ways of ensuring that an application is reliable and efficient before deployment is through software testing. One of the most powerful functional testing techniques that focuses on testing the boundary cases of a system is Boundary Value Analysis (BVA). Boundary Value Analysis finds potential defects that are apt to show themselves on input partition boundaries.

What is Boundary Value Analysis?

Boundary Value Analysis is a black-box testing method which tests the boundary values of valid and invalid partitions. Instead of testing all the possible values, the testers focus on minimum, maximum, and edge-case values, as these are the most error-prone. This is because defects often occur at the extremities of the input ranges rather than at any point within the range.

For example, if a system accepts values between 18 and 56, instead of testing all the values, testers would test the below-mentioned values:

Valid boundary values: 18, 19, 37, 55, 56

Invalid boundary values: 17 (below minimum) and 57 (above maximum)

By running these primary test cases, the testers can easily determine boundary-related faults without unnecessary repetition of in-between value testing.

Implementing BVA: A Real-World Example

To represent BVA through an example, let us take a system processing dates under the following constraints:

Day: 1 to 31

Month: 1 to 12

Year: 1900 to 2000

Under Single Fault Assumption, where one of the variables is tested while others are at nominal values, test cases like below can be written:

Boundary value checking for years (e.g., 1900, 1960, 2000)

Boundary value checking for days (e.g., 1, 31, invalid cases like 32)

Checking boundary values for months (i.e., 1, 12)

By limiting test cases to boundary values, we are able to have maximum test coverage with minimum test effort.

Equivalence Partitioning and BVA together

Another helpful technique is combining BVA and Equivalence Partitioning (EP) together. EP divides input data into equivalent partitions where every equivalence class is expected to behave in the same way. By using these techniques together, testers can reduce the number of test cases but still maintain complete coverage.

For instance, if a system would only accept passwords of 6 to 10 characters long, test cases can be:

0-5 characters: Not accepted

6-10 characters: Accepted

11-14 characters: Not accepted

This mix makes the testing more efficient, especially when using more than one variable.

Limitations of BVA

Although BVA is strong, it does face some limitations:

It works well when the system contains properly defined numeric input ranges.

It has no regard for functional dependencies of variables.

It may not be equally effective on free-form languages like COBOL, which has more flexible input processing.

Conclusion

Boundary Value Analysis is one very important test method that can help testers define most probable fault sites of a system. Merged with Equivalence Partitioning, it has highest test effectiveness at the maximum elimination of test case replication and minimum complete loss of test coverage. In as much as BVA isn’t a “catch-all”, yet it represents an essential technique of software provision quality and dependability.

Personal Reflection

Learning Boundary Value Analysis has helped me understand more about software testing and how it makes the software reliable. It has shown me that by focusing on boundary values, defects can be detected with higher efficiency without generating surplus test cases. It is a very practical approach to apply in real-world scenarios, such as form validation and number input testing, where boundary-related errors are likely to be found. In the future, I will include BVA in my testing approach to offer more test coverage in software projects that I undertake.

Citation

Geeks for Geeks. (n.d.). Software Testing – Boundary Value Analysis. Retrieved from https://www.geeksforgeeks.org/software-testing-boundary-value-analysis/

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

The blog I chose to write about this week details what different types of tests do and how they should be prioritized to test efficiently. The blog post starts with the writer talking about their own experience testing and how early on they tested their program only through the user interface, which quickly showed the downsides of this method. It was slow, couldn’t be run on all devices, and needed manual checks. Testing like this is called end to end testing and it is, slow, expensive, and not always the most revealing about potential problems. Instead, unit tests are much preferred as they test the very basic functionality and are quick. A middle ground between these two is instance or integration testing, which are able to cover most of the program without having to go through a limited user interface. These three types of testing create a pyramid to show that a majority of your cases should be unit tests, then instance tests being next most common, and finally end to end tests.

The distribution pyramid is based on five principles that make up the Smurf mnemonic. The first is speed, that has you prioritize many quick tests that will catch problems sooner. Next is maintainability that gives importance to tests that will scale well or not be subject to many dependencies. Utilization is important when keeping in mind the cost of running your code repetitiously and minimizing the resources used. Reliability states that you should always have tests that will only return an error when something is actually wrong and using these as indicators of crucial issues that need to be addressed. Lastly, fidelity is testing that recreates the users experience from start to finish, or end to end. Each type of test in the pyramid is distributed across these five factors in variable amounts, each showing their use.

I chose this blog because I wanted to learn more about writing test cases for a complete program in a work environment. I thought that this blog did well in that respect and helped in so far as providing an outline to begin with when starting to write test code. One addition that could have improved the post would be some examples, but they are easily accessible elsewhere. This will be a helpful resource and reference to use in the future when I am put in the position where I would need to start writing test from scratch, as well as being something to keep in mind when looking at prewritten tests to compare.

Test Pyramid Google Testing Blog: SMURF: Beyond the Test Pyramid

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

For a lot of the projects I’ve worked on, we didn’t really do testing in the traditional way of actually writing tests. Each method or function we created, we would just use debugging in the actual code itself to figure out which parts of the method is working correctly, which fail safes are activating, and which errors are throwing. There didn’t seem like a whole reason for writing tests using JUnit or something similar when all code went to a dev environment first, and then put to production.

Just recently I started using JUnit a little bit just to find out how useful it could be when practicing coding certain problems. It definitely had some perks to it such as without compiling and building the entire project each time, I could just run the test to check if that certain code piece will function properly or not. But for me, that isn’t really enough to warrant using it all that much, if you have access to a dev environment (which you should), even though it isn’t the “proper” way to do things, I believe that writing debug in code instead of tests, is way more efficient.

If you look at it from a different perspective though, writing tests can also be worthwhile if you’re more into the automation part of developing. Since tests will be ran automatically when compiling your projects, you wouldn’t need to keep adding in more debug statements manually. This could increase efficiency more than what I previously mentioned, but you may not get as much information as needed from the test. If one of your methods isn’t working properly but the test keeps returning an exception or error and you don’t understand the cause of why it’s happening, the previous approach of writing debug statements will be more efficient and in turn, will help you understand where you went wrong.

All in all, I personally believe that both unit testing / testing in general, and writing debugs have their own places when writing software. Obviously I don’t know too much about software testing yet, but the more I learn, there is definitely potential that my opinion on it would change. As of now, writing debugs if there is an issue, or even if there isn’t, seems to help me a lot when understanding each part of what I’m writing in a deeper level and I look forward to learning more about testing to where it could also help me reach that point.

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

This article by
Jeff Gothelf asks the question “Is Agile finally over?” after 20+ years of
implementation to tech field. He argues that even though Agile’s widespread
adaptation hasn’t got the result that Agile was intended for. Many companies
claimed to be “Agile” as they copy each other, but the implementation of it was
shallow or almost non-existent to make changes according to it. Therefore, he
says that agile does not seems working as companies try to make employee follow
set of rules instead of working in following the basic principles of Agile. He
concluded that organizations need to focus on true organizational agility
rather than rigid framework adoption.

This article
caught my attention while searching through the internet as it criticizes Agile’s
current status in the business world as ideal of agile does not really fit in
reality in organization experience. The vague promises and core ideas are often
overlooked to the ‘wants’ of either customer or the organization. The output is
never about efficient program but a program that works made in short amount
time. In the end, it feels like the organization’s internal culture and goals
must align with the methods it adopts to fully be efficient which does not seem
to work for a lot of groups that ‘follows’ agile. Learning that to me, teamwork
following agile principle is hard from top-down management as they try to
follow rules made by the organization to follow the given framework, that is
why agile is not working for many in my opinion.

This got me to
reflect that to practice agile in the future, that I need to try to make sure
that if the company says they do ‘agile’ format for development, I need to check
with others so that if they want ‘agile’ following company standard or the real
agile that I learned in class. I feel like this way even more because when I work
at a part time job, company wanted to follow xyz because and it was annoying
and required lot of process which contradicted for the speed of work they
wanted us to work on. Therefore, no one really followed by the book or the procedures
were implemented shallow, so it was not effective at all, I think this was the same
case for agile in the long run. It feels like agile manifesto was built for
small teams or companies where they could discuss things multiple times in
small groups not to be used by large companies as it will be always shallow or
just another term to company’s rules to schedule how work is done. Therefore, I
feel like widespread use of agile is dying down unlike what the author says
because no one tries to keep that rule in big companies. 

https://jeffgothelf.com/blog/is-agile-over/

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.

This article by
Jeff Gothelf asks the question “Is Agile finally over?” after 20+ years of
implementation to tech field. He argues that even though Agile’s widespread
adaptation hasn’t got the result that Agile was intended for. Many companies
claimed to be “Agile” as they copy each other, but the implementation of it was
shallow or almost non-existent to make changes according to it. Therefore, he
says that agile does not seems working as companies try to make employee follow
set of rules instead of working in following the basic principles of Agile. He
concluded that organizations need to focus on true organizational agility
rather than rigid framework adoption.

This article
caught my attention while searching through the internet as it criticizes Agile’s
current status in the business world as ideal of agile does not really fit in
reality in organization experience. The vague promises and core ideas are often
overlooked to the ‘wants’ of either customer or the organization. The output is
never about efficient program but a program that works made in short amount
time. In the end, it feels like the organization’s internal culture and goals
must align with the methods it adopts to fully be efficient which does not seem
to work for a lot of groups that ‘follows’ agile. Learning that to me, teamwork
following agile principle is hard from top-down management as they try to
follow rules made by the organization to follow the given framework, that is
why agile is not working for many in my opinion.

This got me to
reflect that to practice agile in the future, that I need to try to make sure
that if the company says they do ‘agile’ format for development, I need to check
with others so that if they want ‘agile’ following company standard or the real
agile that I learned in class. I feel like this way even more because when I work
at a part time job, company wanted to follow xyz because and it was annoying
and required lot of process which contradicted for the speed of work they
wanted us to work on. Therefore, no one really followed by the book or the procedures
were implemented shallow, so it was not effective at all, I think this was the same
case for agile in the long run. It feels like agile manifesto was built for
small teams or companies where they could discuss things multiple times in
small groups not to be used by large companies as it will be always shallow or
just another term to company’s rules to schedule how work is done. Therefore, I
feel like widespread use of agile is dying down unlike what the author says
because no one tries to keep that rule in big companies. 

https://jeffgothelf.com/blog/is-agile-over/

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.

This article by
Jeff Gothelf asks the question “Is Agile finally over?” after 20+ years of
implementation to tech field. He argues that even though Agile’s widespread
adaptation hasn’t got the result that Agile was intended for. Many companies
claimed to be “Agile” as they copy each other, but the implementation of it was
shallow or almost non-existent to make changes according to it. Therefore, he
says that agile does not seems working as companies try to make employee follow
set of rules instead of working in following the basic principles of Agile. He
concluded that organizations need to focus on true organizational agility
rather than rigid framework adoption.

This article
caught my attention while searching through the internet as it criticizes Agile’s
current status in the business world as ideal of agile does not really fit in
reality in organization experience. The vague promises and core ideas are often
overlooked to the ‘wants’ of either customer or the organization. The output is
never about efficient program but a program that works made in short amount
time. In the end, it feels like the organization’s internal culture and goals
must align with the methods it adopts to fully be efficient which does not seem
to work for a lot of groups that ‘follows’ agile. Learning that to me, teamwork
following agile principle is hard from top-down management as they try to
follow rules made by the organization to follow the given framework, that is
why agile is not working for many in my opinion.

This got me to
reflect that to practice agile in the future, that I need to try to make sure
that if the company says they do ‘agile’ format for development, I need to check
with others so that if they want ‘agile’ following company standard or the real
agile that I learned in class. I feel like this way even more because when I work
at a part time job, company wanted to follow xyz because and it was annoying
and required lot of process which contradicted for the speed of work they
wanted us to work on. Therefore, no one really followed by the book or the procedures
were implemented shallow, so it was not effective at all, I think this was the same
case for agile in the long run. It feels like agile manifesto was built for
small teams or companies where they could discuss things multiple times in
small groups not to be used by large companies as it will be always shallow or
just another term to company’s rules to schedule how work is done. Therefore, I
feel like widespread use of agile is dying down unlike what the author says
because no one tries to keep that rule in big companies. 

https://jeffgothelf.com/blog/is-agile-over/

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.

This article by
Jeff Gothelf asks the question “Is Agile finally over?” after 20+ years of
implementation to tech field. He argues that even though Agile’s widespread
adaptation hasn’t got the result that Agile was intended for. Many companies
claimed to be “Agile” as they copy each other, but the implementation of it was
shallow or almost non-existent to make changes according to it. Therefore, he
says that agile does not seems working as companies try to make employee follow
set of rules instead of working in following the basic principles of Agile. He
concluded that organizations need to focus on true organizational agility
rather than rigid framework adoption.

This article
caught my attention while searching through the internet as it criticizes Agile’s
current status in the business world as ideal of agile does not really fit in
reality in organization experience. The vague promises and core ideas are often
overlooked to the ‘wants’ of either customer or the organization. The output is
never about efficient program but a program that works made in short amount
time. In the end, it feels like the organization’s internal culture and goals
must align with the methods it adopts to fully be efficient which does not seem
to work for a lot of groups that ‘follows’ agile. Learning that to me, teamwork
following agile principle is hard from top-down management as they try to
follow rules made by the organization to follow the given framework, that is
why agile is not working for many in my opinion.

This got me to
reflect that to practice agile in the future, that I need to try to make sure
that if the company says they do ‘agile’ format for development, I need to check
with others so that if they want ‘agile’ following company standard or the real
agile that I learned in class. I feel like this way even more because when I work
at a part time job, company wanted to follow xyz because and it was annoying
and required lot of process which contradicted for the speed of work they
wanted us to work on. Therefore, no one really followed by the book or the procedures
were implemented shallow, so it was not effective at all, I think this was the same
case for agile in the long run. It feels like agile manifesto was built for
small teams or companies where they could discuss things multiple times in
small groups not to be used by large companies as it will be always shallow or
just another term to company’s rules to schedule how work is done. Therefore, I
feel like widespread use of agile is dying down unlike what the author says
because no one tries to keep that rule in big companies. 

https://jeffgothelf.com/blog/is-agile-over/

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.

This article by
Jeff Gothelf asks the question “Is Agile finally over?” after 20+ years of
implementation to tech field. He argues that even though Agile’s widespread
adaptation hasn’t got the result that Agile was intended for. Many companies
claimed to be “Agile” as they copy each other, but the implementation of it was
shallow or almost non-existent to make changes according to it. Therefore, he
says that agile does not seems working as companies try to make employee follow
set of rules instead of working in following the basic principles of Agile. He
concluded that organizations need to focus on true organizational agility
rather than rigid framework adoption.

This article
caught my attention while searching through the internet as it criticizes Agile’s
current status in the business world as ideal of agile does not really fit in
reality in organization experience. The vague promises and core ideas are often
overlooked to the ‘wants’ of either customer or the organization. The output is
never about efficient program but a program that works made in short amount
time. In the end, it feels like the organization’s internal culture and goals
must align with the methods it adopts to fully be efficient which does not seem
to work for a lot of groups that ‘follows’ agile. Learning that to me, teamwork
following agile principle is hard from top-down management as they try to
follow rules made by the organization to follow the given framework, that is
why agile is not working for many in my opinion.

This got me to
reflect that to practice agile in the future, that I need to try to make sure
that if the company says they do ‘agile’ format for development, I need to check
with others so that if they want ‘agile’ following company standard or the real
agile that I learned in class. I feel like this way even more because when I work
at a part time job, company wanted to follow xyz because and it was annoying
and required lot of process which contradicted for the speed of work they
wanted us to work on. Therefore, no one really followed by the book or the procedures
were implemented shallow, so it was not effective at all, I think this was the same
case for agile in the long run. It feels like agile manifesto was built for
small teams or companies where they could discuss things multiple times in
small groups not to be used by large companies as it will be always shallow or
just another term to company’s rules to schedule how work is done. Therefore, I
feel like widespread use of agile is dying down unlike what the author says
because no one tries to keep that rule in big companies. 

https://jeffgothelf.com/blog/is-agile-over/

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.

This article by
Jeff Gothelf asks the question “Is Agile finally over?” after 20+ years of
implementation to tech field. He argues that even though Agile’s widespread
adaptation hasn’t got the result that Agile was intended for. Many companies
claimed to be “Agile” as they copy each other, but the implementation of it was
shallow or almost non-existent to make changes according to it. Therefore, he
says that agile does not seems working as companies try to make employee follow
set of rules instead of working in following the basic principles of Agile. He
concluded that organizations need to focus on true organizational agility
rather than rigid framework adoption.

This article
caught my attention while searching through the internet as it criticizes Agile’s
current status in the business world as ideal of agile does not really fit in
reality in organization experience. The vague promises and core ideas are often
overlooked to the ‘wants’ of either customer or the organization. The output is
never about efficient program but a program that works made in short amount
time. In the end, it feels like the organization’s internal culture and goals
must align with the methods it adopts to fully be efficient which does not seem
to work for a lot of groups that ‘follows’ agile. Learning that to me, teamwork
following agile principle is hard from top-down management as they try to
follow rules made by the organization to follow the given framework, that is
why agile is not working for many in my opinion.

This got me to
reflect that to practice agile in the future, that I need to try to make sure
that if the company says they do ‘agile’ format for development, I need to check
with others so that if they want ‘agile’ following company standard or the real
agile that I learned in class. I feel like this way even more because when I work
at a part time job, company wanted to follow xyz because and it was annoying
and required lot of process which contradicted for the speed of work they
wanted us to work on. Therefore, no one really followed by the book or the procedures
were implemented shallow, so it was not effective at all, I think this was the same
case for agile in the long run. It feels like agile manifesto was built for
small teams or companies where they could discuss things multiple times in
small groups not to be used by large companies as it will be always shallow or
just another term to company’s rules to schedule how work is done. Therefore, I
feel like widespread use of agile is dying down unlike what the author says
because no one tries to keep that rule in big companies. 

https://jeffgothelf.com/blog/is-agile-over/

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.