很好，这下子我们回到了红灯状态，这正是我们所期望的，现在是时候来考虑实现这个栈了。这个实现过于简单，也有非常多的思路，其中一种是使用一个NSMutableArray来存储数据，然后在top方法里返回后加入的数据。修改VVStack.m，加入数组，更改实现：

 

//VVStack.m
@interface VVStack()
@property (nonatomic， strong) NSMutableArray *numbers;
@end
@implementation VVStack
- (id)init {
if (self = [super init]) {
_numbers = [NSMutableArray new];
}
return self;
}
- (void)push:(double)num {
[self.numbers addObject:@(num)];
}
- (double)top {
return [[self.numbers lastObject] doubleValue];
}
@end

　　测试通过，注意到在-testStackObjectCanBeCreated和testPushANumberAndGetIt两个测试中都生成了一个VVStack对象。在这个测试文件中基本每个测试都会需要初始化对象，因此我们可以考虑在测试文件中添加一个VVStack的实例成员，并将测试中的初始化代码移到-setUp中，并在-tearDown中释放。
 

　　接下来我们可以模仿继续实现pop等栈的方法。鉴于篇幅这里不再继续详细实现，大家可以自己动手试试看。记住先实现测试，然后再实现产品代码。一开始您可能会觉得这很无聊，效率低下，但是请记住这是起步练习不可缺少的一部分，而且在我们的例子中其实一切都是以“慢动作”在进行的。相信在经过实践和使用后，您将会逐渐掌握自己的节奏和重点测试。关于使用XCTest到这里为止的代码，可以在github上找到。

Kiwi和BDD的测试思想
　　XCTest是基于OCUnit的传统测试框架，在书写性和可读性上都不太好。在测试用例太多的时候，由于各个测试方法是割裂的，想在某个很长的测试文件中找到特定的某个测试并搞明白这个测试是在做什么并不是很容易的事情。所有的测试都是由断言完成的，而很多时候断言的意义并不是特别的明确，对于项目交付或者新的开发人员加入时，往往要花上很大成本来进行理解或者转换。另外，每一个测试的描述都被写在断言之后，夹杂在代码之中，难以寻找。使用XCTest测试另外一个问题是难以进行mock或者stub，而这在测试中是非常重要的一部分（关于mock测试的问题，我会在下一篇中继续深入）。

　　行为驱动开发（BDD）正是为了解决上述问题而生的，作为第二代敏捷方法，BDD提倡的是通过将测试语句转换为类似自然语言的描述，开发人员可以使用更符合大众语言的习惯来书写测试，这样不论在项目交接/交付，或者之后自己修改时，都可以顺利很多。如果说作为开发者的我们日常工作是写代码，那么BDD其实是在讲故事。一个典型的BDD的测试用例包活完整的三段式上下文，测试大多可以翻译为Given..When..Then的格式，读起来轻松惬意。BDD在其他语言中也已经有一些框架，包括早的Java的JBehave和赫赫有名的Ruby的RSpec和Cucumber。而在objc社区中BDD框架也正在欣欣向荣地发展，得益于objc的语法本来非常接近自然语言，再加上C语言宏的威力，我们是有可能写出漂亮优美的测试的。在objc中，现在比较流行的BDD框架有cedar，specta和Kiwi。其中个人比较喜欢Kiwi，使用Kiwi写出的测试看起来大概会是这个样子的：

 

describe(@"Team"， ^{
context(@"when newly created"， ^{
it(@"should have a name"， ^{
id team = [Team team];
[[team.name should] equal:@"Black Hawks"];
});
it(@"should have 11 players"， ^{
id team = [Team team];
[[[team should] have:11] players];
});
});
});