How can you simulate dependencies in testing?

An important aspect of software design is to encapsulate your dependencies and create abstractions. As soon as I have to deal with external details like filesystems or HTTP calls, I encapsulate that externality into a module that hides the externality from the rest of the system. The system can then deal with the module in terms of the 'what' while ignoring the 'how'. The aim is to keep my core logic unpolluted by its externalities. The core logic can then be tested in isolation, and it is easy to substitute mocks for all the dependencies. The 'ports and adapters' pattern (also known as 'Hexagonal' architecture) illustrates how to do this well.

Simulating dependencies during Unit Testing is a well known approach, ex dependency to insert data in a DB, dependency to invoke a REST API. Mocking is the approach used to do Unit testing. However, the caveat is : while mocking can be a good strategy , it has its pitfalls. Ex: the REST API returns and invalid response which the application cannot handle. So, one should test the Code with actual dependencies. This should include all kinds of inputs to those dependencies, checking for timeout errors, high concurrent load. For ex, the external REST API might work well with few requests, but might get stuck up when there are 20 requests per min. So all this needs to be part of the testing strategy, with real dependencies (not mock!). Thanks.

It's always not possible to have dependencies at the unit testing level. For example your code might be using some configurations which client code get from server or database. The good software design is always about minimising the dependencies. The more loosely coupled the components and entities of application are , the more it's easy to test. However since dependencies can't be avoided totally but we can try to minimise artificial (technical) dependencies.

Dependencies in testing can be simulated using virtualization tools: wiremock is best tool in the market to mock the APIs you dependent on.

1. There are many types of automated testing. It is important to specify the scope of testing we are discussing here. From perusing the article it seems to be geared towards unit and integration testing. 2. Beginning with FIRST principles and why they are important for quality of tests will help understand why we need to simulate dependencies in the first place. Some factors such as the reliability and speed of the tests are covered here. But that is not the whole picture.

In some cases, relying on mock objects or stubs are fine for specific use case or module. But to test the entire feature/module in a end-to-end perspective, these stubs/mocks are not good enough. To overcome these complexities we can utilise integration testing with the help of test containers or docker containers. In the current era, you can deploy almost any of the components or software with the help of docker images and containers. With the help of docker daemon preinstalled and running multiple docker commands you can spin up most of the software within few mins. Eventually, with the help of docker and test containers you don't need to rely on external components or service to test your application end to end.

Dependencies in your code, like web services or databases, are essential for functionality but can complicate testing. They introduce variables that can make your tests unreliable or hard to interpret. For example, a slow or unavailable dependency could lead to test failures or skewed results. Testing with dependencies often requires more time, resources, and maintenance to ensure accuracy.

To simulate dependencies in testing: Use mocking or stubbing to mimic dependency behavior. Employ dependency injection to provide mock or stub implementations. Create test doubles like dummies, fakes, stubs, and mocks. Consider containerization or in-memory alternatives for external dependencies. Utilize environment variables for configuration switches. Leverage built-in support in testing frameworks. Implement record and playback for certain scenarios. Use in-memory implementations for databases or services. Introduce conditional logic to toggle between real and simulated dependencies as needed.

Dependencies in testing refer to external factors or resources. Software relies on these for correct functionality, like databases or web services.

You can simulate dependencies by using fake or proxy classes. There are many test frameworks like the Google test which provide these dependencies simulation in the form of mock class. One important aspect here is to code for interface not implementation. If your code will be depending on concrete objects then creating fake or mock objects. This is why the Dependency Inversion principle from SOLID is important in terms of testable design.

Mocking api dependencies and using docker for all backing services will help you. This means "Minimize divergence between development and production, enabling continuous deployment for maximum agility" 4. target of 12factorapp

In my past experiences within the micro-service world, I've had many different ways to simulate the dependencies of an application in order to test it thoroughly. Nowadays most applications irrespective of what type they exactly are, live inside containers (Docker, Podman, OCI Based) therefore one challenge is to test them in and out of their containers. Moreover, you may need to test the micro-service against the other containerized dependencies which brings you to reinforce the test strategies in a way to be able to get them up and running during testing. Additionally, you require some data close to reality to have fine-grained testing so data mocking and behavior simulation are needed to consider.

In testing, mocks, stubs, and spies serve different purposes but are often used to isolate the unit of work: - **Mocks**: Used to simulate the behavior of complex objects. They are pre-programmed with expectations and behaviors. Mocks not only simulate the behavior but also track calls and can fail the test if expectations are not met. - **Stubs**: Also isolate the code from external dependencies but are simpler than mocks. They are programmed to return fixed values but don't track calls or fail the test based on behavior. - **Spies**: Similar to mocks but less strict. They record information like function call counts, arguments, etc., without affecting the behavior of the spied function. Unlike mocks, they don't have pre-set expectation

Stubs are simulated components or functions used in software testing. They mimic the behavior of real elements to isolate code under test.

For integration testing when you are testing relationships between services, mocks and stubs can be used. e.g; when we use a mock in the test, it will be faster and less dependent by avoiding making the call to the actual APIs. This provides flexibility to scope the test to cover just the parts we want to control and change. Mocking ensures you are scoping tests to work that you can do and not giving yourself problems you can’t fix. Various test frameworks are available e.g; Mockito, TestNG to handle dependencies.

A stub is a minimal implementation of an interface that helps isolate the unit of code being tested from its dependencies. Stubs are programmed to return specific values or behaviors to enable the testing of different code paths. Unlike mocks, stubs don't track calls or have pre-set expectations; they simply provide predetermined responses. They're useful for simulating the behavior of complex objects without having to rely on the actual object.

When creating a mock, the tester specifies the expected behavior of the object. This includes the methods that the object should respond to, the parameters that the methods should be called with, and the return values that the methods should return.

Mocks are objects that simulate the behavior of real objects in controlled ways, often used in unit testing to isolate code under test from external dependencies. Mocks are pre-programmed with expectations about calls they will receive, the arguments they'll get, and what they should return. They can also record the number of times methods were called, helping in behavior verification. If the mock's expectations are not met, the test will fail.

As I mentioned before mocking can apply on several layers such as data and objects which means in unit testing or component testing of any application according to the programming language that you've utilized there's a plethora of code and objects that could be mocked or stubbed to mimic the behavior of the genuine objects. For example, if you're in need of simulating the behavior of REST APIs you would be able to use WireMock at the component testing (could also be the integration testing), if you're at the unit testing level it could be Mockito helping you out. Besides, there's a brilliant framework to simulate the behavior of well-known containerized applications for testing purposes which is called Testcontainers.

In Test-Driven Development (TDD), a "fake" is an object that has a working implementation, but it takes shortcuts for the sake of testing. Unlike mocks and stubs, fakes have functional logic but are usually simplified and not suitable for production. They're used to isolate code under test from external dependencies, like databases or APIs, while still allowing the test to run quickly and predictably. Fakes provide a way to test how your code interacts with the dependency, without actually involving the real dependency.

In TDD, spies are objects or functions that record how they are called, allowing you to examine their interactions with the code under test. Unlike mocks, spies don't have pre-set expectations or behaviors; they simply observe and record calls. This means they can be less intrusive, as they don't alter the behavior of the function they're spying on. Spies are useful for verifying that certain methods have been called, how many times they were called, and what arguments were passed to them, among other things. They're often used for behavior verification in tests.

I have personally used Mock and Spy objects in Java Unit Testing. Well-known frameworks in Java for mocking objects are Mockito and PowerMockito.

Always follow proper design principles wherever possible. The most important rule here is "Code to interfaces not implementation". It will help in simulating dependencies, where you can pass/use the mock or fake objects in place of original objects.