博士tl;
在Pivotal，我们编写了Cedar，因为我们在Ruby项目中使用并热爱Rspec。Cedar并不是要取代或与OCUnit竞争;它意味着将bdd风格的测试引入Objective C，就像Rspec在Ruby中开创了bdd风格的测试一样，但并没有消除Test::Unit。选择一种还是另一种很大程度上是风格偏好的问题。
在某些情况下，我们设计Cedar是为了克服OCUnit工作方式中的一些缺点。具体来说，我们希望能够在测试中使用调试器，从命令行和CI构建中运行测试，并获得测试结果的有用文本输出。这些东西可能对你或多或少有用。
长回答
在两个测试框架(如Cedar和OCUnit)之间做出选择(例如)可以归结为两件事:首选的风格和易用性。我将从风格开始，因为这只是一个观点和偏好的问题;易用性往往是一组权衡。
风格的考虑超越了您使用的技术或语言。xunit风格的单元测试比bdd风格的测试存在的时间要长得多，但后者迅速流行起来，这主要归功于Rspec。
xunit风格测试的主要优点是它的简单性和广泛采用(在编写单元测试的开发人员中);几乎任何你可以考虑使用的语言都有一个xunit风格的框架。
BDD-style frameworks tend to have two main differences when compared to xUnit-style: how you structure the test (or specs), and the syntax for writing your assertions. For me, the structural difference is the main differentiator. xUnit tests are one-dimensional, with one setUp method for all tests in a given test class. The classes that we test, however, aren't one-dimensional; we often need to test actions in several different, potentially conflicting, contexts. For example, consider a simple ShoppingCart class, with an addItem: method (for the purposes of this answer I'll use Objective C syntax). The behavior of this method may differ when the cart is empty compared to when the cart contains other items; it may differ if the user has entered a discount code; it may differ if the specified item can't be shipped by the selected shipping method; etc. As these possible conditions intersect with one another you end up with a geometrically increasing number of possible contexts; in xUnit-style testing this often leads to a lot of methods with names like testAddItemWhenCartIsEmptyAndNoDiscountCodeAndShippingMethodApplies. The structure of BDD-style frameworks allows you to organize these conditions individually, which I find makes it easier to make sure I cover all cases, as well as easier to find, change, or add individual conditions. As an example, using Cedar syntax, the method above would look like this:
describe(@"ShoppingCart", ^{
describe(@"addItem:", ^{
describe(@"when the cart is empty", ^{
describe(@"with no discount code", ^{
describe(@"when the shipping method applies to the item", ^{
it(@"should add the item to the cart", ^{
...
});
it(@"should add the full price of the item to the overall price", ^{
...
});
});
describe(@"when the shipping method does not apply to the item", ^{
...
});
});
describe(@"with a discount code", ^{
...
});
});
describe(@"when the cart contains other items, ^{
...
});
});
});
在某些情况下，您会发现其中的上下文包含相同的断言集，您可以使用共享示例上下文来DRY这些断言集。
bdd风格框架和xunit风格框架的第二个主要区别是断言(或“匹配器”)语法，它只是让规范的风格更好一些;有些人喜欢它，有些人不喜欢。
导致易用性的问题。在这种情况下，每个框架都有其优点和缺点:
OCUnit has been around much longer than Cedar, and is integrated directly into Xcode. This means it's simple to make a new test target, and, most of the time, getting tests up and running "just works." On the other hand, we found that in some cases, such as running on an iOS device, getting OCUnit tests to work was nigh impossible. Setting up Cedar specs takes some more work than OCUnit tests, since you have get the library and link against it yourself (never a trivial task in Xcode). We're working on making setup easier, and any suggestions are more than welcome.
OCUnit runs tests as part of the build. This means you don't need to run an executable to make your tests run; if any tests fail, your build fails. This makes the process of running tests one step simpler, and test output goes directly into your build output window which makes it easy to see. We chose to have Cedar specs build into an executable which you run separately for a few reasons:
We wanted to be able to use the debugger. You run Cedar specs just like you would run any other executable, so you can use the debugger in the same way.
We wanted easy console logging in tests. You can use NSLog() in OCUnit tests, but the output goes into the build window where you have to unfold the build step in order to read it.
We wanted easy to read test reporting, both on the command line and in Xcode. OCUnit results appear nicely in the build window in Xcode, but building from the command line (or as part of a CI process) results in test output intermingled with lots and lots of other build output. With separate build and run phases Cedar separates the output so the test output is easy to find. The default Cedar test runner copies the standard style of printing "." for each passing spec, "F" for failing specs, etc. Cedar also has the ability to use custom reporter objects, so you can have it output results any way you like, with a little effort.
OCUnit is the official unit testing framework for Objective C, and is supported by Apple. Apple has basically limitless resources, so if they want something done it will get done. And, after all, this is Apple's sandbox we're playing in. The flip side of that coin, however, is that Apple receives on the order of a bajillion support requests and bug reports each day. They're remarkably good about handling them all, but they may not be able to handle issues you report immediately, or at all. Cedar is much newer and less baked than OCUnit, but if you have questions or problems or suggestions send a message to the Cedar mailing list (cedar-discuss@googlegroups.com) and we'll do what we can to help you out. Also, feel free to fork the code from Github (github.com/pivotal/cedar) and add whatever you think is missing. We make our testing frameworks open source for a reason.
Running OCUnit tests on iOS devices can be difficult. Honestly, I haven't tried this for quite some time, so it may have gotten easier, but the last time I tried I simply couldn't get OCUnit tests for any UIKit functionality to work. When we wrote Cedar we made sure that we could test UIKit-dependent code both on the simulator and on devices.
最后，我们为单元测试编写了Cedar，这意味着它不能与UISpec这样的项目相提并论。我尝试使用UISpec已经有一段时间了，但我认为它主要专注于在iOS设备上以编程方式驱动UI。我们特别决定不让Cedar支持这些类型的规格，因为苹果(当时)即将宣布用户界面自动化。
