mock object methods

Description

In MXUnit the return value of a mocked object (as returned by mock()) can be replaced as follows:

This does not work in TestBox's compat and makes it cumbersome to switch from MXUnit to TestBox.

Reference the first example, here: https://github.com/mxunit/mxunit/wiki/Defining-a-Mock's-Behaviour

See also TESTBOX-54. The ticket is closed (but not resolved) and has a note about calling mock without arguments, which is valid in MXUnit but not TestBox's compat.

Activity

Show:
Ben Botto
June 5, 2018, 7:37 AM

Okay, thanks for the response, . I completely understanding dropping support for MXUnit. But that said, it would be helpful to have some sort of a migration guide for those of us coming over (or trying to, at least!) from MXUnit.

I'll also point out that the above code is not really a viable migration route because of the "path" argument, but maybe createStub would work.

Luis Majano
June 5, 2018, 7:39 AM

Thanks . I will update this guide: https://testbox.ortusbooks.com/in-depth/mxunit-compatibility

With some of your feedback.

Also, yes, `createMock()` is a typed a approach. If you don't care about types, then use `createStub()`.

Luis Majano
June 5, 2018, 7:40 AM

Let me also add , that we will be glad to help you migrate away from MXUnit. Are you in our box team slack?

It might not be that we update the core for certain things, but we will be glad to help in any way we can.

Ben Botto
June 5, 2018, 7:43 AM

I'm not sure of the box team is the box-products channel in cfml.slack.com, but, if so, then yes, I'm in there. I've been in the chat as Sna4x8 since the IRC days! =)

Luis Majano
June 5, 2018, 7:44 AM

You can join our official support slack here: http://boxteam.herokuapp.com/

The entire Ortus team is behind this team, so responses are better and more granular for any of our products.

Won't Fix

Assignee

Luis Majano

Reporter

Ben Botto

Labels

None

Components

Priority

Major