编写可执行规范的好软件和技巧
我正在从事的项目已经到了可执行规范非常有用的地步。我们资源不足，但我们确实有专人负责系统质量，他们有时间编写这些规范。他并不是真正的程序员，这就是为什么需要一个在高度抽象甚至可能是 GUI 方面提供大量帮助的框架。
我一直在研究黄瓜和讲故事的人，但由于我写这些东西的经验有限，我很难决定哪一个是最好的。因此，如果在这些方面有经验的人能给我一些关于如何做这件事的指导，甚至可能是一些能让我们的生活更轻松的好软件的技巧，我将会很有帮助。实施此操作时我需要考虑什么问题吗？有什么已知的陷阱吗？或者可执行规范可能完全是一个坏主意？任何意见都非常感谢。
该系统运行在.Net平台上，因此您推荐的任何软件都必须与其兼容。
The project I'm working on has gotten to the point where executable specs would be of great use. We are low on resources, but we do have someone in charge of system quality that would have time to write these specs. He is not really a programmer, which is why a framework that provides a lot of help in terms of high abstractions or possibly even a gui would be desirable.
I've been looking into cucumber and storyteller, but since I have limited experience in writing these things I'm having a hard time deciding which one is the best. I would therefore be much helped if any of you with experience in these things could give me a few pointers on how to go about doing it, and maybe even some tips of good software that will make our lives easier. Are there any concerns that I need to take into consideration when implementing this? Any known pitfalls? Or is it parhaps that executable specs are a bad idea altogether? Any input is much appreciated.
The system runs on the .Net platform, so whatever software you recommend must be compatible with this.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
对于非程序员来说，关于可执行规范的好提示很难找到，因为您编写的是当前项目中的目标。
这是一个两难的困境，因为您希望运行测试，但必须尽可能将其描述为非技术性的。
我认为您需要将问题重新表述为“非极客如何学习编写可执行规范”或类似的问题。
我想分享我在最近的一个项目中的发现，我想在该项目中编写一个简短的烟雾测试（cucumber/webrat/mechanize）。因此，测试使用 webrat 运行 cucumber，这为规范部分提供了一个非常非技术性的界面。
黄瓜规范相当高水平（尽管在幕后技术）
但是，非极客必须了解有关页面的一些内容才能编写规范。例如，您经常需要查找搜索字段、按钮等的名称。
技术设置：
就我而言，我想要一个简单易用的解决方案，非技术人员可以继续从几个示例中指定。我选择了基于 Cucumber+Webrat+Mechanize 的设置。
它通过标准 HTTP 请求与应用程序进行对话。 （请注意，这阻止了我做 javascript 的事情，并且实际上是当前项目的一个优势，该项目必须通过政府指南以实现无需 javascript 的可访问性）
Webrat 的规范语法非常简单：“当我遵循 [链接文本] 时”， “当我点击[按钮]”，“那么我应该看到“关于我们：””，等等。
我对非技术人员的建议：
从一些你的极客已经合并到代码中的示例中学习。也许您的开发人员已经创建了“overview.feature”，其中包含 3-4 个在您的应用程序上实际运行和传递的示例场景
了解如何查找表单字段的 ID 或名称。例如，您可以使用带有名为“Firebug”插件的 Firefox 浏览器。在这里，您可以通过右键单击网页中的任何元素来激活名为“检查元素”的功能。
一般来说，请尝试使用非技术语言来描述您的规范。不要仅仅因为你更好地学习了 Cucumber/Webrat 语言而编写过于复杂的表达式。请记住，您的规范应该由那些不知道自己正在阅读可以实际执行的规范的人来阅读。
如果您有兴趣，我可以分享这个项目的引导代码。
Good tips for executable specs are hard to angle at non-programmers as you write is your target in your current project.
It's a dilemma as you want the tests to run but must be described as non-technical as possible.
I think that you need to reformulate the question to "How non-geeks can learn to write executable specs" or similar to that.
I want to share my findings from a recent project where I wanted to write a short smoketest (cucumber/webrat/mechanize). So the test runs cucumber with webrat, which gives a pretty non-technical interface to the spec part.
The cucumber specs then are pretty high-level (although tecnical under the hood)
However, the non-geeks have to understand some stuff about the pages in order to write the specs. For instance, often you need to look up names of search fields, buttons, etc.
TECHNICAL SETUP:
In my case, i wanted a simple-to-use, solution that non-tech people could continue to specify from a few examples. I settled for a setup based on Cucumber+Webrat+Mechanize.
This talks to an application via standard HTTP requests. (Note that this prevents me from doing javascript stuff, and is actually an advantage on the current project that has to pass government guidelines for accessibility without javascript)
Webrat has a very simple syntax for specs: "When I follow [link text]", "When I click [button]", 'Then I should see "About us:"', etc.
MY RECOMMENDATIONS TO NON-TECH people:
Learn from a few examples that your geek has already incorporated in the code. Perhaps your developer has created "overview.feature" that contains 3-4 example scenarios that actually run and pass on your application
Learn how to find id or name of a form field. For instance, you can use the Firefox browser with a plugin called "Firebug". Here you can activate a feature called "Inspect element" by right clicking any element in your web page.
In general, try to keep your specs in a non-technical language. Resist from writing overly complex expressions just because you learn the cucumber/webrat language better. Keep in mind that your specs should be read by people who have no clue that they are reading specs that can actually execute.
If you are interested I can share my bootstrap code for this project.