Changelog History
-
v0.7.0 Changes
April 22, 2019๐ This release adds the new stub syntax which is a great improvement over the old double/allow syntax.
stub
combines both into one function now:dbl = ModuleOrBehavior |> stub(:function_name, fn(x) -> x end) |> stub(:another_function, fn(x) -> x end) dbl.function_name("hello") assert_receive({ModuleOrBehavior, :function_name, ["hello"]})
You'll notice that the message now contains the module or behavior atom that the stub is built against. This prevents conflicts w/ function names between different modules and is another improvement that the
stub
syntax provides.๐ The old double/allow syntax is no longer documented, but isn't marked as deprecated yet. We may consider that in the future, or maybe even dropping support for it in version 1.0.
๐ For more details on the new syntax, please read the docs!
-
v0.6.6 Changes
February 06, 2019๐ This release includes fixes to prevent conflicts with auto imported functions from Kernel. Thanks to @JonRowe for the contribution!
-
v0.6.5 Changes
May 18, 2018๐ This is only a documentation update.
-
v0.6.4 Changes
January 21, 2018๐ Fixes warnings for Elixir 1.6 and applies new built-in code formatter. Credit to @take-five
-
v0.6.3 Changes
October 07, 2017๐ This release includes a fix for the typespec on
allow/3
. -
v0.6.2 Changes
August 19, 2017๐ This release fixes an issue with verifications on module based doubles that have macros. Macros can now be stubbed whereas they would have thrown a verification error before.
For example, Logger.info/1 is a macro that you can now stub and it will be properly verified.
logger_stub = Logger |> double() |> allow(:info, fn(_msg) -> :ok end)
-
v0.6.1 Changes
July 27, 2017๐ This release will start essential Double services as part of an OTP application. This should help with with intermittent errors with starting and stopping services. Thanks @take-five!
-
v0.6.0 Changes
June 21, 2017Clearing Stubbed Functions
Occasionally it's useful to clear the stubs for an existing double. This is useful when you have
โ a shared setup and a test needs to change the way a double is stubbed without recreating the whole thing.stub = IO|\> double|\> allow(:puts, fn(\_) -\> :ok end)|\> allow(:inspect, fn(\_) -\> :ok end)# laterstub |\> clear(:puts) # clear an individual functionstub |\> clear([:puts, :inspect]) # clear a list of functionsstub |\> clear() # clear all functions
-
v0.5.1 Changes
June 21, 2017๐ Prevents module conflict warnings from leaking. It has been observed that occasionally a module conflict warning would leak into test output. This is likely due to concurrent evaluations and the global nature of the setting to ignore those warnings. This release puts that evaluation in a single GenServer to ensure that only one evaluation takes place at a time.
-
v0.5.0 Changes
June 21, 2017Behaviour Doubles
Now a module defining a behaviour can be used as the source of a double. The callbacks will be used in the set of functions verified for proper function name and arity when stubbing.
defmodule TestBehaviour do @callback process(String.t) :: :ok end test "example behaviour stubbing" do process_stub = TestBehaviour |> double |> allow(:process, fn(_arg1) -> :ok end) # This will work fine |> allow(:boom, fn -> :ok end) # This will throw a VerifyingDoubleError because it's not defined. end
Stubbing against a behaviour may be especially useful when working in a project where the behaviour implementation should be a client concern and you don't have a concrete module to stub against.