2001年，我开始向团队进行教学驱动的开发。然后它仍然是一个相当新的概念。很少有球队有任何形式的自动测试，并且仍然听说过XP和TDD的更少。首先用作设计活动作为设计活动的写作测试是一个完全外国的概念，人们很难掌握它。 （这一事实完全没有改变，二十年了。）
这是那些日子里的艰难卖。我很难以最佳方式展示概念，并带来团队。但这真的很难，我挣扎着。更重要的是，我旨在解决的问题：我教导的人挣扎着。
我在那些日子里遇到的常见问题之一是“测试”这个词的困难。不仅仅是“测试”这个词，而且TDD周围的所有词汇都是理解的，以非常定心的为中心。人们非常困惑。 “你无法测试某些不存在的东西，”他们曾经说过，而且经常他们被沾沾自喜，“因此你的整个前提是有缺陷的。” “测试”这个词给他们一个借口忽视我发现非常有价值的概念和方法，我试图改变这一点。
在寻找解决方案时，我了解了语言相对性的SAPIR-WORF假设，这提出了通过改变用于传达思想的词语，我可以影响如何接收和解释这个想法。我周围的其他人也发现了这一点。 AslakHellesøy，丹北和Liz Keogh，在这列火车上发布了一些，并提供了很多洞察力和帮助。
所以我开始创建在我的培训中使用的工具。我想删除以测试为中心的词汇表。要略微翻译先知，“测试不是首选的命名法，伙计。”到2003年，我开始使用Ruby教授TDD。在那些日子里，Ruby仍然是一个利基语言。 Ruby在Rails上尚未通过风暴带来世界，但我很欣赏它是一种适当的面向对象语言，我可以用来实施这些想法。
当与其他类似的心灵配对时，我发现他们的测试都有一个名称，如test_should_do_this_thth。这个词测试仍然存在，但他们正在使用更好的单词来沟通意图：应该。
我们如何摆脱单词测试？在Ruby中，我们可以轻松删除它。所以我有一个计划：创建用于教学TDD的工具，以描述完成的软件应该具有的行为。这个想法当时仍然是新的，但代表了TDD的创造者一直在说什么：自动化测试会传达完成的软件应该拥有的行为。
我创建的第一个工具是一个名为descripter.rb的小型ruby文件，它只是旨在删除单词测试。它看起来像这样：
要求＆＃39;测试/单位＆＃39;描述= test :: unitcontext = testcase＃重新定义测试::单位:: testcase.suite使用与＃34开始的方法;应该＆＃34;而不是＆＃34;测试＆＃34;
现在我们可以在没有使用这个词的情况下写下测试！这是一个精美的简单解决方案：我们仍然使用Ruby内置标准库中存在的所有精彩工具，包括强大的跑步者集，同时使新的从业者能够使用不同的单词，不会产生无法创建认知似乎不断使用“考试”一词造成的不和谐。
我将其纳入我的TDD培训。在我的研讨会中，我们将使用此单个文件来编写我们的软件说明。我在训练中使用这个词停止了。突然间围绕“测试”一词消失了。
在我的每个培训课程中，我在最后一天举行这一点。在最后一天，我会告诉大家：“你正在写的这些东西可以编写你的软件。它们实际上代表了一个可以运行的自动测试套件以测试软件并确保它充当正确的方式。“我会展示我的课程，这是你在这里留下时你在Ruby中在Ruby中写下测试的方式：
它的工作！我希望我的与会者使用“标准工具”，但我希望他们用一个新的心态接近它。最终测试词汇的引入允许我的与会者使用标准工具，但要从预期的角度来处理问题。最后，我的培训是提供所需的价值，并达到更广泛的人。以前可能是非常耐受性的人。
我的课程中的剩余问题以及我最初没有注意到的问题，是逆转对断言的参数的与会者。我的与会者很常见，以反转其断言中的预期和实际值，导致错误消息令人困惑。我承认我偶尔就犯了这个错误，但熟悉它，我很快就识别了这个错误。我试图通过以读取更像纯语言的方式写期望来解决这个问题。我添加了一个拍摄块的方法assert_that，您可以使用返回对象上的断言。
此解决方案是一个只适用于课堂的单个文件库的大量代码。所以我看了一种更简单的方式。随着Ruby的力量，我们可以解决这个问题！所以我把我的脚趾浸入了成分曲线图中，并将断言混合到对象。 （这是发布的图书馆中的错误，但它真的很高兴。）
随着这种变化，教学工具已完成。但它没有释放。它只存在于我的研讨会中。我从来没有打算任何人在我的研讨会外使用这个：我认为他们应该使用标准库中存在的工具。 XUNIT模式很好地理解，几乎所有语言都可以提供，并且非常受支持。我认为将新图书馆添加到混合中，这将是一个巨大的错误，并忍受了这个维护。
我想，没有必要新工具，只改变了一些单词使用。在后智，我认为这对课堂来说是一个有价值的活动，这是愚蠢的，但这并不一定是练习的宝贵活动。
我从不想发布这个工具。 XUnit存在，并适合目的。对我来说，成为rspec的东西只不过是一个教学工具，我认为它不应该住在课堂外。但是，我被强迫了。
在2000年代中期，Bob Martin试图在引入TDD时发挥相同的印象。他说同样的事情是别人说，但以不同的方式说：“测试是关于规范没有验证。”他谈到了测试作为“软件可执行规范”。
我喜欢这个框架，但我总是有“规范”这个词的问题。我仍然。对我来说，一个从RFC和规格实施许多东西的互联网上，这个词规范是一个保留的单词，不应用于新目的。我以为我们应该找到一个新的词。
但是当时鲍勃马丁是我的英雄，他在以规范的词汇表达了以下一篇下列。他显示了我为我的研讨会创建的工具的演示，并联系了我鼓励我释放它。他强烈鼓励我专注于以规范为中心的词汇表。
我仍然认为RSPEC是RSPEC的错误名称。当我第一次给予释放它的想法时，我仍然称之为“描述的人”，我以为我可能会做一天的流行事物：掉落e并致电它描述。但我也没有真正满意这个名字，我没有觉得我有资格与鲍勃马丁争论它应该被称为什么。所以rspec出生。
我对那一点的RSPEC非常满意，作为一个教学工具，但我仍然认为任何人都不应该使用它。人们爱上了这个想法，他们真的想以这种方式编写他们的测试。这让我惊讶地抓住了如此广泛，而且很快。此事上有调查，一些报告，高达90％的Rails项目中的新Ruby of On Rails项目途中使用它而不是内置XUnit样式框架。很快，“RSPEC克隆”开始在几乎所有其他语言中弹出。
围绕rspec被发布，具体域语言的想法也变得流行。作为使用语言来改变人们对软件的方式的粉丝，我想看看我们是否可以通过创建一个完整的DSL来指定软件的行为来更好地制作RSPEC。
Joe O'Brien和我在Rubyconf 2005上配对了这一件事。我们使用的单词与现在使用的单词不同，但该想法是坚实的。什么乔和我在Rubyconf配对2005年结束了看起来像这样的东西：
指定＆＃34;添加数字＆＃34; {IT_Should＆＃34;在提供的数字和＃34中添加一个。 {add_one（1）.should_equal 2}}
我们希望的这种变化会导致人们完全停止思考代码，并开始专注于软件的所需行为。对于我们将RSPEC转变为DSL的事实，我仍然非常满意。
将RSPEC制作完整的DSL是，我认为，我最后一个真正的代码对项目的贡献。我仍然没有使用rspec我自己，因为我认为它是一个教学工具，并且竞选使用“标准”利用。自从我（仍然是）以多种语言工作，我想在我的工作中使用类似的工具。我不明白为什么，在学习考虑TDD的合适方式后，他们会选择使用DSL导致与对象模型的尴尬交互的非标准库。
因为我不明白为什么人们使用rspec，我没有自己使用它（迄今为止，我只使用它已经开始使用它的项目;我不是自己选择它），我没有觉得我将是该项目的适当管家。还有许多其他对项目的未来更兴奋的人比我更兴奋。因此，在2006年或2007年的某些时候，我将该项目达到其最多产，重要的贡献者达到日期：大卫·切伍斯基。
Chelimsky是该项目的惊人管家。我无法对此做出更正确的选择。将RSPEC交给越来越多的（比我更有能力，特别是）David Chelimsky的手可能是我对项目的最积极的贡献。更积极，甚至而不是创造它。
我也想（朴素，历史记录已经表明，到目前为止，RSPEC不会成为我整个软件行业所做的唯一持久贡献。我坚持不懈，在2007年，我不会成为一个诡计的小马。我仍然希望我留在我身上有很多技巧，但我不太自信，我将能够以类似的方式再次移动针头。我会诚实：这一事实使我多年来悲伤。
我做了很多错误。主要的一个更柔软：我建立了一个人喜欢的东西，改变了他们的思维方式，我强烈抵制了它并允许他们以自己的方式使用它。直到多年后，我开始“谢谢”谢谢人们的消息，告诉我他们无法进行TDD和BDD，或者根本测试，直到他们遇到RSPEC。我很谦卑，对这些消息感到欣赏，对不起，我试图妨碍你。
在技术前面：将断言混合成对象是错误的。它对早期的采用者引起了很多痛苦，并且在项目的早期，我们花了很多时间在这一决定上加倍，并解决这造成的问题而不是重新思考和改变期望格式。在未来的版本中纠正了预期（预期的）。在我看来，在我看来，这是写期望的最完美的方式，并且更接近我在犯下混合之前的原始实验目的。如果你在早期花了这一点，我很抱歉痛苦的痛苦，在糟糕的决定中加倍，并导致你在建立更强大的软件时努力受到困扰。
我也会后悔让别人为自己的工作带来信誉。我的早期导师，我在这里没有名字，因为他已经证明自己是一个以自我为中心的，一般令人憎恶的人，并且在后代是一个可怕的导师，试图告诉别人他创造了他创造了rspec。创建了RSPEC之后他建造的事情是RSPEC基于和灵感的东西。 RSPEC基于许多人的代码和知识的贡献，但这个个人对该项目的实际贡献很小，并且在早期有限公司限于窃取别人的代码并抛弃许可证标题，这是我发现所难以应对的事情。
最后，我后悔自己和我创造的东西之间的距离。我认为我可以在空间中建立更多有用的工具，并在更大的方式帮助更多的人，如果我有点接受人们使用我为目的以外的目的创造的事实而言。我很抱歉没有帮助更多的人。
我很感激有机会以一定的方式为软件社区做出贡献，并帮助人们实现自己的潜力。 我希望能够帮助更多的人在未来意识到自己的潜力。 我永远感激对我的创作欣赏，它在世界上继续使用。 对于人们给我买的很多啤酒感谢我感谢我从不想发布的事情。 我希望在这个小马中留下了更多的技巧，但现在我专注于帮助个人和团队尽最大努力。 我将继续对我能做的许多小贡献感到满意，并感谢与人们合作的机会帮助我做出这些贡献。 而且我很感激未来的贡献，我会有帮助我帮助他们的人，我希望我能让软件的发展只是一个涉及的每个人都有一点点更好。