A library for defining concurrent mocks in Elixir based on explicit behaviour contracts.
Mox is a library for defining concurrent mocks in Elixir that helps developers write better tests by enforcing explicit contracts between application components. It solves the problem of testing code that depends on external services or complex dependencies by providing a structured approach to mocking that maintains test concurrency and promotes clear interface design.
Elixir developers building applications with external dependencies or complex internal components who need to write concurrent, maintainable tests. It's particularly useful for teams practicing test-driven development or working on applications with clear service boundaries.
Developers choose Mox because it enforces best practices for mocking through behaviour-based contracts while supporting concurrent test execution. Unlike ad-hoc mocking approaches, Mox promotes explicit interface design and maintains test performance through its no-dynamic-module-generation approach.
Mocks and explicit contracts in Elixir
Open-Awesome is built by the community, for the community. Submit a project, suggest an awesome list, or help improve the catalog on GitHub.
Mocks can only be created based on Elixir behaviours, forcing developers to define clear interfaces between components, as emphasized in the library's philosophy to promote better software architecture.
By avoiding dynamic module generation per test and defining mocks once in setup, tests using the same mock can run with `async: true`, improving test suite performance as highlighted in the README.
Uses function clauses and pattern matching for input validation instead of complex expectation rules, making tests more readable and aligned with Elixir's idiomatic style, as noted in the key features.
Lacks built-in support for verifying call counts, sequences, or spies, requiring manual implementation for complex test scenarios, which the README acknowledges by relying solely on pattern matching.
Requires defining behaviours, mock modules, and application configuration switches, adding initial complexity compared to simpler mocking approaches, especially for small or rapidly evolving projects.
If the application doesn't use behaviours or has poorly defined interfaces, integrating Mox necessitates significant refactoring, limiting its usefulness in legacy or tightly coupled codebases.