> For the complete documentation index, see [llms.txt](https://hanfak.gitbook.io/workspace/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://hanfak.gitbook.io/workspace/testing-reading-maintaining/testing-1/social-unit-tests.md). # social-unit-tests ## Social Tests ### What * Also known as * documentation tests * acceptance unit tests * module tests * test that verifies the behavior of a unit (e.g., a class or a function) in collaboration with its real dependencies rather than mocking them * Any infrastructure calls (ie http, message bus, files etc) are stubbed/faked out * Writing tests without using mocks/spies, but using stubbed out (test implementation of dependencies with possible extra logic or static factories in prod code used only for test), to test several classes at a time. * Used in testing the core of hexagonal architecture * With business rules being tested * with the ports implementing fakes * Adapters not tested * Avoiding use of mocks to verify * as these are dealt with ....???? * * Care about the output * ie the reponse * This is a testing pattern, and not a hammer * should be have reasons to use, and use other tests type ### Characteristics * Real Collaborators: The unit interacts with its actual dependencies. * Integration-Like: Tests a small part of the system, often a subset of the domain or application logic, an aggregate * Behavior-Oriented: Focuses on the outcome of the collaboration rather than internal implementation details. * Limited Scope: While broader than solitary tests, they do not span the entire application stack (e.g., they exclude the database or external systems). ## Advantages * Thus allowing ease of refactoring, as code is not tied test implementation. * validate the actual collaboration between multiple units, rather than have fine grained tests * When testing the business logic in a domain-driven design or hexagonal architecture, sociable tests ensure domain entities and value objects work together correctly. * Example: An aggregate root interacting with child entities to enforce invariants. * Good for handling complex interactions. * When interactions between multiple components are too complex to mock effectively without missing edge cases or creating brittle tests. * Example: Validating the flow of a process where components communicate heavily (e.g., an order placement pipeline). * Avoiding Mocking Overhead: * Sociable tests are beneficial when mocking dependencies would introduce unnecessary complexity or make the test fragile. * Example: A calculator service that depends on multiple reusable utility classes. * Avoid testing implementation, and focus on testing behaviour * Focused on business rules: * avoid testing situations that will never happen in a business flow, * example: as the calling object calling it might never have the state that could be used in the test. * Can be used with BDD language and be read by business * Avoid mocking/stubbing business rules that might return the wrong thing * Less end to end acceptance tests ### Disadvantages/When not to use * Testing Behavior with External Systems or boundaries: * Avoid sociable tests for interactions with databases, file systems, network APIs, or other external systems. * This is integration tests * Highly Independent Units: * If a unit has minimal or no interaction with other components, a solitary unit test is sufficient. * Example: Testing a string utility function or a pure algorithm. * Complex algorithms/rules: * Can start off with a social test, but might be easier to unit test the rules/algorithm separately and easier (ie remove dependency graph) * Non-Deterministic Behavior: * unsuitable for systems with non-deterministic behavior (e.g., random number generation, time-based behavior) unless the randomness can be controlled. * Example: A test that depends on real-world timing or randomness. * Complex Dependency Graphs * hen the dependency graph is too complex, as this can lead to brittle and slow tests. * Example: A service relying on many indirect dependencies through deeply nested calls. * This can be handled via a factory * Performance Concerns: * Can be slow due to complex setups or large numbers of interacting components, they may not be ideal for fast feedback loops. * Can be harder to isolate failures * When multiple units are involved, it can be difficult to pinpoint which unit is causing a test failure. * Will need to use a debugger more * Limited Fault Injection * It’s harder to simulate specific edge cases or failure scenarios compared to solitary tests with mocks or stubs. * Example: Testing how a service handles an exception from a dependency may require significant effort to trigger that failure * Overlap with Integration Tests * may duplicate the purpose of integration tests, leading to redundancy and wasted effort. * Reduced Control Over Dependencies * use real dependencies, which means they lack the fine-grained control provided by mocks or fakes. * A dependency that randomly changes its state (e.g., based on system time) might cause sporadic test failures. * Real dependencies may introduce non-determinism (e.g., caching, threading, random inputs), making tests unreliable. * Potential Over-Reliance * Overusing sociable tests can lead to insufficient solitary unit tests, which are crucial for pinpointing issues within individual units. * ### Examples ### Links *