Troubleshooting

This page lists common issues you may encounter and how to resolve them.

You must link against either XCTest or SenTestingKit frameworks.

This happens on Xcode 6 if you only have Cedar specs in your test bundle because the XCTest framework is not explicitly linked unless there are XCTest classes. You can work around this problem in the meantime by editing the build settings for your test bundle. Search for 'Other Linker Flags' and add -framework XCTest to the list. Don't worry if it splits over multiple lines.

<tr1/memory> file not found

This happens on new Xcode 4.5 projects where the defaults now use C++11. Cedar will eventually switch over once we phase out support for iOS 4.x (which does not ship with the C++11 standard library).

Until then, you'll have to change the "C++ Standard Library" build setting for your spec target to libstdc++ (instead of the default, libc++).

Linker problem ld: file not found

Happens with spec bundles. Example failure:

ld: file not found: <path to build dir>/Products/<Configuration>-<device>/<target name>.app/<target name>
clang: error: linker command failed with exit code 1 (use -v to see invocation)

• This error occurs when there is an incorrect target name used.
• The target name should match the application your tests are running against.
• To fix this, update the Bundle Loader setting in build settings to $(BUILT_PRODUCTS_DIR)/<target name>.app/<target name> ensuring that your new target name is the correct.

Linker problem ld: symbol(s) not found

Example failure:

Undefined symbols for architecture i386:
"_OBJC_CLASS_$_SomeClassFromYourApp", referenced from:
    objc-class-ref in SomeClassFromYourAppSpec.o
    (maybe you meant: _OBJC_CLASS_$__OBJC_CLASS_$_SomeClassFromYourApp)
ld: symbol(s) not found for architecture i386

This error can happen when you have a spec bundle which is run against code built with "Strip Debug Symbols During Copy" set to Yes.

You should ensure that you're running your tests against code built with this configuration setting set to No. This should be the default if you're building with the Debug configuration.

be_same_instance_as / be_nil fails complaining pointer arguments are non-pointers

Example failures:

FAILURE …
Attempt to compare non-pointer type for sameness.

FAILURE …
Attempt to compare non-pointer type to nil

This is caused by a C++ compiler bug in all current versions of Xcode when ARC is enabled and you use a Cedar matcher like be_same_instance_as or be_nil with an Objective-C object. You have 3 ways around this problem:

1. Use an indirect comparison and check for truthiness. For example:

foo == bar should be_truthy; // instead of foo should be_same_instance_as(bar)
foo == nil should be_truthy; // instead of foo should be_nil

2. Disable ARC for your spec files, but continue to use it for your application code. You can do this by selecting spec files in the target's "Compile Sources" build phase and adding the compiler flag -fno-objc-arc. You can help ensure that you do this by creating a SpecHelper.h file in your spec target that you #import into every spec which contains this guard:

#if __has_feature(objc_arc)
#error ARC must be disabled for specs!
#endif

3. Use another matcher library like Expecta. Just remove the following line from your spec files:

        using namespace Cedar::Matchers;

No matching function to call

Example failure:

error: no matching function for call to 'CDR_expect'
note: candidate template ignored: substitution failure [with T = SOME_TYPE]

This is caused by a C++ compiler bug in versions of Xcode prior to 4.5 when ARC is enabled and you use a Cedar matcher. You have 3 ways to avoid this problem:

1. Switch to Xcode >= 4.5

2. Disable ARC for your spec files, but continue to use it for your application code. You can do this by selecting spec files in the target's "Compile Sources" build phase and adding the compiler flag -fno-objc-arc. You can help ensure that you do this by creating a SpecHelper.h file in your spec target that you #import into every spec which contains this guard:

#if __has_feature(objc_arc)
#error ARC must be disabled for specs!
#endif

3. Use another matcher library like Expecta. Just remove the following line from your spec files:

using namespace Cedar::Matchers;

ld: symbol(s) not found for architecture i386

In some situations linker might be unable to reference symbols in the application object files (*.o) when building the Cedar Spec target. One solution is to make application symbols available via setting "Symbols Hidden by Default" to "No" in "Build Settings". Below is an example of the error that can be fixed by making symbols not hidden.

"_OBJC_CLASS_$_AppDelegate", referenced from:
      objc-class-ref in ExampleSpec.o
ld: symbol(s) not found for architecture i386
clang: error: linker command failed with exit code 1 (use -v to see invocation)

Moreover, if you encounter other linker issues a good litmus test is to build your app and spec target in using Debug configuration.

EXC_BAD_ACCESS

If you find that your controller's views appear to be allocated and initialized, but their bounds are not set, it's possible that you cloned the cedar project from a repo and that .xcuserdata is in the .gitignore file. The result of this is that the CEDAR_HEADLESS_SPECS environment variable is lost on the spec target.

To fix this, edit your schemes, select your Cedar Spec target, and add the CEDAR_HEADLESS_SPECS=1 ENV variable.

be_instance_of fails even though the class appears to be the same

When using test bundles, if you inadvertently add your production code classes to your Specs test bundle target as well as to your main target, you may see confusing failures that look like:

Expected <<Foo: 0x7fa522ccf350> (Foo)> to be an instance of class <Foo>.

This can occur because there are actually two copies of class Foo loaded into the runtime, which are not equal to each other. The solution is to ensure that the classes you are testing are only added to your main target.