Close
Glad You're Ready. Let's Get Started!

Let us know how we can contact you.

Thank you!

We'll respond shortly.

LABS
Too many parentheses

Cedar comes with its own built-in matcher library and here is Adam Milligan’s blog post that explains on how to use it. An example of expectation written using Cedar matcher library:

expect(controller.button).to_not(be_nil());

Even though this is much better than OCHamcrest it is still not satisfying (in my opinion) because there are so many parentheses involved. Since Cedar matcher library is written in C++ we can do some magic here. The result is you can write your expectations like this:

controller.button should_not be_nil;

So let’s dig into how Cedar’s should syntax is implemented.

  controller.button   should_not   be_nil
|-------------------|------------|--------|
    actual value       C macro     matcher

As you might have guessed should and should_not are C macros. Besides making possible for each expectation to know its filename and line number (with __FILE__ and __LINE__ preprocessor variables), they also hide the unnecessary complexity which makes this syntax possible. Here is how it looks expanded:

  controller.button   ,(ActualValueMarker){__FILE__, __LINE__},true,   be_nil
|-------------------|------------------------------------------------|--------|
    actual value                        mumbo jumbo                    matcher

So how does this mumbo jumbo work? Since Cedar matcher library was written in C++ we can overload the comma operator. Besides being a weird operator to overload, it has a useful property that we can exploit here. Comma operator has the lowest precedence among all other operators and that allows us to write 2+2 should equal(4) instead of (2+2) should equal(4). Now let’s break mumbo jumbo into pieces:

(1) <actual value>
    (ActualValueMarker){__FILE__, __LINE__} -> (2) ActualValue
                                                   true/false  -> (3) ActualValueProxy
                                                                      <matcher>

(1) This step captures actual value (can be anything since it is templated), filename and line number. It is implemented like this:

template<typename T>
const ActualValue<T> operator,(const T & actualValue, const ActualValueMarker & marker) {
    return ActualValue<T>(marker.fileName, marker.lineNumber, actualValue);
}

(2) Now we overload comma operator to match ActualValue (returned from step 1) and a bool that indicates whether matcher result should be negated.

template<typename T>
const ActualValueMatchProxy<T> operator,(const ActualValue<T> & actualValue, bool negate) {
    return negate ? actualValue.to_not : actualValue.to;
}

(3) And finally we overload comma operator again so that it matches ActualValueMatchProxy (returned from step 2) and anything else. Second argument will be considered to be a matcher.

template<typename T, typename MatcherType>
void operator,(const ActualValueMatchProxy<T> & matchProxy, const MatcherType & matcher) {
    matchProxy(matcher);
}

That’s pretty much all. Full implementation of should syntax (which is just several more lines more than what is shown above) can be found in ShouldSyntax.h (and corresponding spec file that makes sure syntax works). Everything above allows us to write expectations as follows:

controller.button should_not be_nil();

Since the goal is to get rid of as many parentheses as possible we still have some work to do. Nil matcher that comes with Cedar is implemented with BeNil class. The way it worked before was be_nil was a function defined in Cedar::Matchers namespace. Calling it each time would return a new instance of BeNil class. To make parentheses go away be_nil was turned into a static variable that is initialized only once to an instance of BeNil class. (be_nil matcher still supports being used with two parentheses for backwards compatibility by implementing call operator on BeNil class.) Bam.

controller.button should_not be_nil;

Usually it is not recommended to use operator overloading for non-operator related purposes (e.g. don’t use + operator for subtraction); however, in this case I think it’s fine to bend the rules just a bit to escape all those parentheses and provide clean expectation DSL. You can use should syntax with the latest Cedar master branch.

Comments
Post a Comment

Your Information (Name required. Email address will not be displayed with comment.)

* Copy This Password *

* Type Or Paste Password Here *