Lmst

Jasmine Crockett ‘Liked’ Posts Calling Abbott ‘Hot Wheels’ in 2021, Undercutting Her Explanation for Deriding Wheelchair-Bound Governor https://freebeacon.com/democrats/jasmine-crockett-liked-posts-calling-abbott-hot-wheels-in-2021-undercutting-her-explanation-for-deriding-wheelchair-bound-governor/ via @FreeBeacon #HotWheels #Disabilities #Mocking #TheDigitalFreePress

📢 Microcks has joined the LFX Mentorship Program with 7 projects! 🎉

We’re welcoming 7 mentees to contribute the #opensource way, advancing API #mocking & #testing.

Want to optimize your mentorship application?
Check out our insights & tips! 👇
https://www.linkedin.com/pulse/microcks-feedback-mentorship-applicants-yacine-kheddache-5bcme/

Cloud Native Computing Foundation (CNCF) / CNCF TAG App Delivery / The Linux Foundation 🙌

#FuckYou ... Its the #GulfOfMexico #FuckFealty #Mocking #Taunting looking straight into the maws of #Evil

Given the major pre-work from Ryan Hoegg (shamsoft) i've been diving back into my coding passion, resulting in a major evolution of sham-ssh. https://github.com/janesser/sham-ssh #java #sshd #mocking

Mocking MQTT with Playwright #mqtt #playwright #mocking #testing

https://camillovisini.com/coding/mocking-mqtt-with-playwright

Mocha v3.0.0-rc.1 released

Looking for people to test the release candidate! 🙏

Highlights:

* Allow keyword arguments to match an expectation expecting *only* positional arguments
* Explicit support for Ruby v3.4
* Freeze all string literals used internally
* Use Ruby v1.9 Hash syntax in failure messages
* Drop support for Ruby v2.1
* Drop support for Minitest < v5

https://rubygems.org/gems/mocha/versions/3.0.0.pre.rc.1

Thanks to Herwin W, Nicholaus Ames, Sean Dilda & @drewnovo.

#ruby #testing #mock #mocking #opensource

From AI-Aware Sites to AI-Aware APIs: Introducing the AI-Ready Isolator++ API by Eli Lopien. https://www.typemock.com/introducing-the-ai-ready-isolator-api/ #ai #apis #cpp #unittesting #mocking #programming

From AI-Aware Sites to AI-Awar...

Mocha v2.7.1 released

* Deprecate `Configuration#stubbing_method_on_nil=` in preparation for dropping support for Ruby v2.1

* Indicate when parameter matcher logic is defined by block passed to `Expectation#with`

* Improve documentation for `Expectation#with`, especially when it is passed a block

https://rubygems.org/gems/mocha/versions/2.7.1

#ruby #testing #mock #mocking #opensource

Mocha v2.7.0 released

* Fail fast if invocation matches never expectation - thanks to Duke Tran & @DavidStosik for reporting

This fixes a long-time bug so that the following will fail fast instead of passing:

foo.stubs(:bar)
foo.expects(:bar).never
foo.bar # => unexpected invocation error

https://rubygems.org/gems/mocha/versions/2.7.0

#ruby #testing #mock #mocking

Mocha v2.6.1 released

* Fix logic added in v2.6.0 for displaying deprecation warnings for expectation with never cardinality - thanks to @DavidStosik for reporting.

The following will still pass despite an erroneous deprecation warning displayed in v2.6.0 suggesting otherwise:

foo.expects(:bar).never
foo.expects(:bar).once
foo.bar

https://rubygems.org/gems/mocha/versions/2.6.1

#ruby #testing #mock #mocking

Mocha v2.6.0 released

* Expectation with never cardinality should display deprecation warning - thanks to Duke Tran for reporting and testing.

In anticipation of fixing a long-time bug so that the following will fail fast instead of passing:

foo.stubs(:bar)
foo.expects(:bar).never
foo.bar # => deprecation warning / unexpected invocation error

https://rubygems.org/gems/mocha/versions/2.6.0

#ruby #testing #mock #mocking

I apparently missed this post from @maelle on #mocking #tests in #RStats packages, specifically recommending `testthat::local_mocked_bindings()` over `mockery::stub()` and giving a clear example of how to mock base functions.

https://blog.r-hub.io/2024/03/21/mocking-new-take/

Very pertinent today as one of the codebases I'm working on used `mockery::stub()` and my colleague found that it was leaking to other tests in a pattern that could only be described as...

vicious mockery (roll 1d4 for damage)

The Risks of Mocking Frameworks: How Too Much Mocking Leads to Unrealistic Tests

Extensive use of mocking frameworks such as Mockito in software development can lead to unrealistic tests. This is because mocking frameworks simulate dependencies of classes or methods in order to test them in isolation. However, when too many mock objects are used, the test often loses touch with reality, which can affect the validity and reliability of the tests. It is important to use mocking carefully to find the right balance between isolated testing and realistic simulation.

A mock is a simulated object that imitates the behaviour of a real component without executing any actual logic. This is particularly useful when a dependency is difficult to test, for example, because it involves an external database or web service that may have states that are difficult to reproduce or where testing would be very time-consuming and costly. Mocking creates a simplified and manageable version of this dependency, allowing targeted and isolated unit testing to be carried out. Mocking can be a precious technique in these cases, especially for writing independent tests that do not require external infrastructure. It reduces the complexity of tests and makes them faster and more deterministic.

However, it becomes problematic when the logic of the tested class is heavily influenced by these dependencies, especially when these dependencies have complex logic or dynamic behaviour. For example, a class that reads data from a database might implement logic that responds to the available data contents. This dynamic nature often cannot be realistically replicated with mocks, as mock objects are usually limited to predefined, simple return values. As a result, the test can lose touch with the objective complexity and only inadequately reflect the actual application logic. Realistic tests are created that only consider some possible application behaviours in interaction with other components, resulting in incomplete test coverage.

Extensive use of mocks often results in tests being tailored very specifically to the simulated scenarios. In such cases, the tests become helpful only for the implemented interfaces and the programmed code rather than for the actual use cases, which may contain a variety of unexpected events and uncontrolled factors. This can lead to a false sense of security that the application is functioning correctly, even though essential real-world conditions still need to be considered. For example, network failures, errors in data transmission or inconsistent data sets could not be simulated in the mocks because the tests focus only on positive confirmation of the function. This means that critical errors that could occur in a natural environment are missed, leading to severe problems in the production environment. To combat this, mocking should be used judiciously, and tests should also be performed that incorporate real-world dependencies to ensure that the code works correctly under real-world conditions such as network problems, database failures, or changing data.

A concrete example of this would be an application that retrieves data from a REST API and processes it. In a typical scenario, this REST API could return different data sets, ranging from simple JSON responses to complex, nested structures. When you replace the REST API with a mock object, you only simulate a specific reaction, which is highly simplified and mostly represents the ‘happy path’. In reality, however, the REST API could react in various ways: data could be missing, the data structure could change, new fields could be added, or network problems and unexpected error messages could occur. Additionally, errors such as receiving an empty response or submitting an HTTP error (e.g. 500 or 404) are often problematic to represent when only a mock is used. Tests based only on mocks cannot adequately simulate these realities because they need to consider the multitude of possible scenarios and failure cases that can arise in actual operation. This leads to a false sense of security about the robustness of the code. If the code is only tested in a strictly controlled environment, without considering the real variability of the API and its potential failures, serious errors may appear in the production environment that were never previously detected. Using accurate integration tests that respond to actual API responses and errors would be much more realistic in this case and would help ensure application robustness under real-world conditions.

Another problem arises when the extensive use of mocks oversimplifies the dependencies. For example, consider an e-commerce application that performs inventory checking. In a real-world implementation, this inventory check can involve a variety of complex operations, such as synchronising inventory across multiple geographically distributed warehouses, honouring reservations for ongoing orders, or updating inventory in real-time. These tasks require sophisticated logic, potentially involving numerous systems and technologies, to ensure inventories are always accurate. When you fully mock a warehouse management class, these complex dependencies are replaced with simple, simulated return values. However, this means that the test loses connection to the real functioning of the system. There is no guarantee that synchronisation logic will work smoothly under real-world conditions, such as network delays or inconsistencies between warehouses. The complexity of the real system is never taken into account in the tests, so possible sources of error remain undetected. In a production environment, unforeseen problems could arise that could have been avoided with a more realistic test environment. These complex scenarios show that real integration tests are necessary to ensure that the interaction between the components works correctly, even under load conditions or in the event of errors in the dependencies.

Another problem arises when test implementations are created too specifically for the mock scenarios. It often happens that developers unconsciously tailor the mock configuration exactly to the logic being tested without taking into account the realistic spread of the data or the potential errors. This results in the tests not reflecting unforeseen events that may occur in a real environment. An example of this is a database query where the test always assumes a successful query because the mock was configured that way. The realistic error case of a database failure, a zero response or a timeout is not practised. This means that the corresponding error handling is noticed in the production environment once it has already had an impact, which can lead to critical problems. Such gaps in error handling could be avoided if tests included a more realistic and varied simulation of possible scenarios. Therefore, tests must also cover hostile and unpredictable scenarios to ensure the application is robust enough to handle errors and exceptions.

Another problem when using mocking frameworks is that the functionality of the mocks only sometimes follows the actual implementation. Often, a simplified or even incorrect replica of the real components is created, which only reflects some aspects of real behaviour. For example, when replicating an external service using a mock, certain side effects, state changes, or dependencies in the real implementation cannot be adequately considered. This can cause the test to pass even though the actual implementation would fail due to its complexity.

Let’s take an example of a Java application that accesses an external cache service to cache data. Suppose we have a class `ProductService` that reads product information from a database and stores it in a cache to improve performance. In a unit test, the cache service method could easily be mocked to ensure the `put()` call runs correctly. The corresponding Java code could look like this:

import static org.mockito.Mockito.*;public class ProductServiceTest {    @Test    public void testFetchProduct() {        CacheService cacheService = mock(CacheService.class);        DatabaseService databaseService = mock(DatabaseService.class);        ProductService productService = new ProductService(databaseService, cacheService);        Product product = new Product("123", "TestProduct");        when(databaseService.getProduct("123")).thenReturn(product);        productService.fetchProduct("123");        verify(cacheService, times(1)).put("123", product);    }}

This test verifies that the product is cached correctly. However, it is not tested here whether the cache mechanism really works as desired, e.g., whether the cache is actually used for repeated requests to avoid unnecessary database queries. Such an error could go undetected in production if, in reality, the cache service is not functioning properly due to a synchronisation issue or misconfiguration. In addition, concurrent accesses to the cache could lead to synchronisation problems that need to be taken into account by simple mocking.

This test, therefore, provides no guarantee that the cache logic will work correctly under real-world conditions such as high load or concurrent accesses. The mocks only represent a simplified version of reality without taking into account all the possible scenarios that could occur in a real environment. Therefore, in addition to unit tests that use mocks, it is crucial also to perform integration tests that ensure that the cache service works correctly under realistic conditions. A classic example would be a component that internally uses caching mechanisms to minimise the number of requests to an external service. A simple mock could ignore the caching mechanism, so the test only checks whether a request is sent correctly to the external service, but not whether the caching logic works as intended. This allows cache management bugs or inefficient implementations to go undetected. Mocks also often do not realistically represent competing accesses to a resource, which could lead to synchronisation problems in the real implementation. Therefore, it is essential to ensure that mocks are as close as possible to the actual implementation to ensure realistic testing scenarios.

An alternative to mocking is integration or end-to-end testing, which tests the actual components and dependencies. Integration testing helps ensure that the application’s various modules interact with each other as expected, while end-to-end testing verifies the overall system under realistic conditions. This does not use mocks but rather real databases, REST APIs and other services, which better simulate the complexity of the real environment.

Another alternative is so-called ‘contract testing’. Contract testing checks whether communication between two services occurs according to a defined specification. This allows both sides of the communication to be developed and tested independently without simulating the entire service. This ensures a certain level of security that both components work correctly with each other without resorting to extensive mocking.

In addition, test containers or in-memory databases can be used as alternatives to mocks, especially for database testing. Using tools like Testcontainers, real database instances can be deployed in Docker containers for testing so that real database logic is tested. In-memory databases like H2 in Java are also useful for making testing more realistic because they simulate actual data logic but without the cost and complexity of a real database connection.

Another alternative method is the use of so-called ‘fake’ objects. Unlike mocks, which only simulate behaviour, fakes implement a reduced version of the real logic. These fakes are not as complex as the real components but still offer more realism than simple mocks. An example of this would be a ‘fake’ database object that mimics basic storage operations in a simple data structure rather than actually connecting to a database. Fakes are particularly useful when you need a realistic but not fully functional, environment to test certain aspects of the application. They are more flexible than mocks and provide the ability to run through different scenarios without simulating the full complexity of real implementations.

In summary, excessive use of mocking frameworks like Mockito often results in tests not being realistic. The isolation of components enabled by mocking is useful for performing isolated unit testing. However, if too many aspects of the application are simulated, the tests lose the ability to represent the interaction of real components and the actual challenges that might arise in operation. There is then a risk that the software in real operation will not show the behaviour that the tests suggest. It, therefore makes sense to find a balance between mocking and integration tests in order to represent realistic scenarios adequately. At the same time, other techniques, such as contract testing or the use of fakes, should also be considered to ensure that the tests replicate the real environment as closely as possible, thus ensuring a robust and reliable application.

Happy Coding

Sven

#Java #mocking #tdd