Open-Source Testing · eproxus

meck

Meck is an Erlang mocking library that lets developers dynamically create mock modules, set expectations on function calls, and validate behavior during testing. It's been actively maintained since 2010 and handles complex scenarios like exception testing, pass-through behavior, and call history inspection.

Talk to DEV.co Discuss Implementation

Source: GitHub — github.com/eproxus/meck

837

GitHub stars

230

Forks

Erlang

Primary language

Apache-2.0

License (OSI-approved)

Key facts

Objective fields from the source. Values we can't verify are shown as “Unknown” rather than guessed.

Field	Value
Repository	eproxus/meck
Owner	eproxus
Primary language	Erlang
License	Apache-2.0 — OSI-approved
Stars	837
Forks	230
Open issues	13
Latest release	v1.2.0 (2026-05-27)
Last updated	2026-05-28
Source	https://github.com/eproxus/meck

What meck is

Meck rewrites and reloads Erlang modules in the global namespace to intercept function calls, supporting parameterized expectations, exception handling, Hamcrest matchers, and optional pass-through to original implementations. The library is process-linked by default and integrates with standard Erlang test frameworks (EUnit, Common Test).

Quickstart

Get the meck source

Clone the repository and explore it locally.

terminalbash

1git clone https://github.com/eproxus/meck.git2cd meck3# follow the project's README for install & configuration

Need it deployed, integrated, or customized instead? DEV.co ships production installs.

Best use cases

Unit testing Erlang applications with isolated module dependencies

Mock out external module calls to test business logic in isolation. Set expectations on what functions should be called with which arguments, then verify call history and return values.

Testing exception handling paths

Use meck:exception/2 to throw controlled exceptions and verify that code under test handles them correctly without invalidating the mock.

Partial mocking with pass-through behavior

Keep most of an original module's functionality while overriding specific functions, useful for testing integration points or intercepting certain calls.

Implementation considerations

Meck modifies the global module namespace; affects all processes in the VM, not isolated to a single test. Unload mocks properly to prevent cross-test contamination.
Set up mocks in the test case body or use no_link flag when creating in setup functions to avoid unloading before tests run.
Use meck:validate/1 after tests to ensure mocks were called as expected; unexpected calls or exceptions will fail validation.
Consider passthrough option for modules where only certain functions need mocking, reducing risk of breaking unintended internal behavior.
Be aware that mocking sticky modules (e.g., system modules) requires the unstick option and may have unpredictable side effects.

When to avoid it — and what to weigh

Mocking gen_* server family or core runtime modules — Meck cannot reliably mock gen_server, gen_statem, supervisor, erlang, os, crypto, or similar core modules that are tightly coupled to running processes or use Native Implemented Functions.
Relying on module-local function interception — Internal calls within a mocked module (e.g., a/0 calling c/0 without explicit module qualification) will bypass the mock and call the original function. Expectations only apply to external calls.
Using Common Test init_per_suite without no_link flag — Mocks created in init_per_suite will unload before test cases run because they're linked to the isolated setup process. Use the no_link option or create mocks in the test case itself.
Mocking in frameworks that depend on timer module — Mocking timer can interfere with Elixir's ExUnit or other test frameworks that rely on it internally, causing unexpected test behavior.

License & commercial use

Licensed under Apache License 2.0 (Apache-2.0), a permissive OSI-approved open-source license.

Apache 2.0 permits commercial use, modification, and distribution with minimal restrictions (retain license notices, disclose changes). Review your organization's policy on open-source dependencies, but this license is generally safe for commercial Erlang projects.

DEV.co evaluation signals

Editorial assessment — not user reviews. Directional, with an explicit confidence level.

Signal	Assessment
Maintenance	Active
Documentation	Adequate
License clarity	Clear
Deployment complexity	Low
DEV.co fit	Good
Assessment confidence	High

Security considerations

Meck operates at the module-reloading level in the Erlang runtime; it has the capability to intercept and modify function calls globally. No security posture details are stated. Malicious expectations or mocks could be used to manipulate module behavior if untrusted code modifies mock definitions. Use mocks only in test contexts with trusted test code. No public vulnerability disclosures noted.

Alternatives to consider

Elixir's built-in mock (via Mox or similar libraries)

If migrating to Elixir, consider Elixir-native mocking solutions; Meck is Erlang-specific and may have impedance mismatches with Elixir patterns.

Common Test built-in test doubles / manual stubs

For simpler projects or when avoiding dynamic module reloading, manually-written stubs or test doubles give explicit control without global namespace side effects.

Property-based testing (PropEr, QuickCheck)

For behavioral testing rather than isolation, property-based generators can explore edge cases without needing to mock dependencies.

Software development agency

Build on meck with DEV.co software developers

Our Erlang engineering team can help you design test strategies, implement mocking patterns, and integrate Meck into your CI/CD pipeline. Contact us to discuss your testing needs.

Talk to DEV.co

Related open-source tools

Surfaced by semantic similarity across the DEV.co open-source index.

microcks httpmock mockk

Related on DEV.co

Explore the category and the services that help you build with it.

Open-Source Testing API Development Application Development Enterprise Software Talk to DEV.co

meck FAQ

Can Meck mock modules that don't exist?

Yes, use the non_strict option: meck:new(module, [non_strict]). By default, Meck will error if the module doesn't exist.

Why does my internal function call still use the original code instead of the mock?

Meck mocks external calls only. Internal module-local calls (e.g., a/0 calling c/0 without explicit module qualification) bypass the mock. Qualify the call explicitly (e.g., ?MODULE:c()) to apply the mock.

How do I prevent mocks from unloading when my test setup process terminates?

Pass the no_link option to meck:new/2: meck:new(module, [no_link]). Then ensure meck:unload/1 is called in cleanup (e.g., end_per_suite) to avoid mock pollution between tests.

Does Meck work with Elixir?

Meck is Erlang-native and can be used in Elixir projects that run Erlang code, but Elixir has its own mocking libraries (e.g., Mox) that integrate more naturally with ExUnit.

Software development & web development with DEV.co

Adopting meck is usually one piece of a larger software development effort. As a software development agency, DEV.co provides software development services and web development expertise — pairing senior software developers and web developers with your team to design, build, and operate open-source testing software in production.

Need Help Implementing Meck in Your Erlang Project?

Our Erlang engineering team can help you design test strategies, implement mocking patterns, and integrate Meck into your CI/CD pipeline. Contact us to discuss your testing needs.

Talk to DEV.co Schedule a Consultation