Receive and beEvaluated matchers, mocks

[trimmurrti]

Recently, Kiwi anounced, that they are dropping the support and future development, so I'm thinking about transitioning to Expecta. One thing, that holds me back, is that there are some matchers and features, which I use all the time and which are absent in expecta. Namely, receive matcher, mocks, evaluation matcher for blocks (see my pull request here: kiwi-bdd/Kiwi#673 ).

I can implement them in expecta, but I was wondering, if it would be in vein with expecta philosophy to implement such a functionality? So, could please someone shed some light on the issue?

[orta]

Expect is built to be expanded on, you could happily create these matchers and release them as a library that exists outside of Expecta - we've got quite a lot of these now. Given the complexity of that PR, I'd probably say that's a better place for it.

Though I'd wait on the Kiwi responses in kiwi-bdd/Kiwi#662 too, it does look like a lot of work.

[trimmurrti]

Wasn't as much for Kiwi, as it had a foundation to build on. It would be an awful lot of work for Specta/Expecta on the other hand. That's why I'm asking about the philosophy, as that would require a lot of changes to the base test classes to implement properly). That's the exact reason why simple matcher creation won't do in that case. Only fork, only hardcore, sadly. As Specta/Expecta is positioned as light weight, I was wondering, if it would actually be any good for the framework.

As for Kiwi, in the light of the Kiwi discussion you took part in, I doubt they will review the pull, as it's would surely be classified as a large commit (base classes had to be changed as well) and Kiwi maintainers told, that they are not going to accept such pulls in the upstream prior to the final release.

[orta]

I'm not adverse to it, but my philosophy on Specta/Expecta is a part of what inspired the Kiwi philosophy.

So long as it's well tested, easy to maintain and if questions come up in the future I can ping you about it, then it's OK by me.

[trimmurrti]

Got your point. Thank you. I will review the Specta/Expecta code a bit more to figure out, what should go where and how to best tackle the issue at hands. From the discussion thread you sent, did I get it right, that there are no new features implemented, but in case of bugs in the core lib in the future, it will still be supported?

If I take on the issue (as this is a lot of work and I need to analyze, how I would approach the task and how I would transition my companies internal projects to Specta/Expecta), I would of course be available after the implementation it in case something is not right. I can't promise though, that I will be able to fix it immediately leaving all my duties behind, but I would surely spend my weekends (and weekdays, if available) to make it work properly.

As for the maintenance ease, could you please explain what do you mean? Do you mean documentation, comments and tests of the functionality, along with code readability, proper naming and stuff? Or something else entirely?

[orta]

As for the maintenance ease, could you please explain what do you mean?

Just the usual PR things, I've received PRs with all the variables in Chinese, and not really been able to say I can accept it as I can't maintain and understand it if I need to.

From the discussion thread you sent, did I get it right, that there are no new features implemented, but in case of bugs in the core lib in the future, it will still be supported?

Yep, I'm not planning on building anything new, but I'm keeping it ticking, I have tens of projects relying on Specta/Expecta, it's not going anywhere.

I can't promise though, that I will be able to fix it immediately leaving all my duties ...

Don't worry, I'm not after a contract, just that I can @trimmurrti you occasionally if it looks like something related to those changes

[trimmurrti]

Well, as I previously mentioned, I don't mind fixing and helping out on the weekends as well.

Got your point.

Still, after reviewing your OCMock specta repo, I'm thinking, if modifications to the base repo are even worth it. Because, after examining it Specta/Expecta/OCMock expecta repo more closely, I see, that there are ways of actually implementing everything I need in a less intrusive way. In that case, the base repo will stay clean of my experiments, while mocking behaviors would stay external.

The only real downside of a less intrusive way, is that you would have to do that in a dealloc method (the same way you did). But I can bear with this ::--))

Still, thank you very much for your prompt and informative responses. In case you need spare hands with Specta/Expecta issues/problems, don't hesitate to contact me.

[orta]

👍