Component testing tools are all about calling functions. Your tests cause functions to be called in "fixtures" that then call into the SUT. Any tool based on this premise will encounter the problems you reference above.
However, most of those problem are manageable. For example you should not be writing lots of fixtures. If you are, something is wrong. Secondly, your fixtures ought to be little more than wiring code to call the APIs in your application. If your fixtures are doing significant work, then something is wrong.
In most FitNesse environments the number of fixtures is rather small. For example, there are over two hundred acceptance tests for fitnesse itself, but the number of fixtures in on the order of a dozen, and they are all relatively simple.
Get help on the [email protected] site. The folks there are usually very responsive to questions.
随着它最终被更多地使用，我添加了另一个样式表，以便在 Web 浏览器中很好地呈现 xml 文件。测试框架生成了它自己的文档。
在另一个项目中，我们需要一个非常基本的模拟/刺激环境来模拟一个人在我们没有的硬件上投掷开关和按下按钮。只需几个小时就可以将测试框架改造为模拟器。创建该框架需要做一些工作，但我们认为从长远来看它确实带来了好处。我真的相信，创建自己的工具会产生这些不可预见的后果，这就是敏捷社区和敏捷社区中的人们所关注的原因。尤其是 XP 一直都是如此强烈的拥护者。
If you can communicate with your software using text, then I have had success on past projects rolling my own framework using expect.
The framework I cooked up stored tests as XML files, using a simple xUnit style markup. The xml files were then transformed into executable tests using a stylesheet. I ended up transforming the tests into Tcl/Expect, but you could transform them into anything. In fact, if you wanted, you could transform them into multiple languages, depending on your needs.
Several people have kindly reminded me (in the same way you remind you poor dottering grandfather about the drool on his chin) that we are in the 21st century when they inquire why I would choose Tcl over some more modern language. As it turns out, for the purposes of this kind of testing, I haven't yet found a better choice. The Tcl language still kicks butt in this area. Trust me, I didn't wake up one day and say to myself "self, what I need a test framework implemented in a scripting language everyone will hate!"
Believe it or not, I really was looking for a tool, any tool, that had the following characteristics:
Cross platform. This was non-negotiable. We do a lot of cross platform development and we already use WAY too many tools that don't support cross platform development.
Simple syntax. Say what you want about Tcl, but the syntax is very regular. I knew that some native code would probably creep even into the XML files (and originally it was Tcl only, no XML) and I wanted the syntax to be comprehensible to a non-programmer. This simplicity is a core strength of Tcl. As it turns out, it also made transforming the XML easier too.
Free. My favorite price ;-)
Writing tests as simple xml files allowed non-programmers to write customer acceptance level tests - no programming required.
Easily extended.
I did not set out to home grow this to the extent I have. Initially, I looked at established test frameworks like DejaGnu and android. Mostly they had way too many features. They were so feature laden that I didn't think they would be easy for a project to start using without a lot of up front training. Looking at DejaGnu, got me interested in Tcl in general, and after a brief look at tcltest, I almost gave up. Both DejaGnu and tcltest assume you are an advanced Tcl scripter, which I didn't think anyone at my company ever would be. In addition, I wanted the test framework (if possible) to support an xUnit type of test framework and neither of these tools did.
Eventually I found TclTkUnit, a Tcl based testing framework that is designed along xUnit lines. It was only a short leap of logic to realize I could run TclTkUnit in Expect instead of tclsh and get everything I needed.
As it ended up getting used more, I added another stylesheet to render the xml files nicely in a web browser. The test framework generated it's own documentation.
On another project we needs a very basic sim / stim environment to emulate a person throwing switches and pushing buttons on a piece of hardware we didn't have. It only took a few hours to hack the test framework to function as a simulator. Creating the framework took some work, but we felt that it did pay benefits in the long run. I really believe that these types of unforseen consequences of creating your own tools is why people in the agile community & XP in particular have always been such strong advocates.
We have adopted a Fitnesse-based but practically-code-free approach using GenericFixture (google for Anubhava to find his wordpress site) for Fitnesse. What this allows us to do is to create "executable test narratives" using a language that is friendly to the business-side (as opposed to the technical-side). This language, which is very easily defined, practically without coding, in Generic Fixture, is called a DSL (domain specific language). So we can write our test narratives using e.g. medical terms or even in a language other than English. Basically what we get is transforming our Use Cases into executable narratives. We are starting to use it in a large project (15 ppl for 2 years) and it seems (so far) to have a good future. It easily allows Test Driven Development or test-creation after development (traditional approach). It is wiki-based (Fitnesse) and its versioning and refactoring funcitonality has proven so far sufficient. I can give more info if anyone is interested.
We use unit-testing frameworks like NUnit to drive our subsystem tests as well - the tests don't care how they are run. It doesn't have fitnesse's document-based approach, though.
发布评论
评论（4）
组件测试工具都是关于调用函数的。您的测试会导致在“装置”中调用函数，然后调用 SUT。任何基于此前提的工具都会遇到您上面提到的问题。
然而，大多数问题都是可以解决的。例如，您不应该编写大量的装置。如果是的话，就有问题了。其次，您的装置应该只不过是在应用程序中调用 API 的连接代码。如果您的设备正在做大量工作，则说明有问题。
在大多数 FitNesse 环境中，固定装置的数量相当少。例如，fitnesse本身的验收测试就有两百多个，但固定装置的数量却有十几个，而且都比较简单。
在[电子邮件受保护]网站上获取帮助。那里的人通常对问题非常敏感。
Component testing tools are all about calling functions. Your tests cause functions to be called in "fixtures" that then call into the SUT. Any tool based on this premise will encounter the problems you reference above.
However, most of those problem are manageable. For example you should not be writing lots of fixtures. If you are, something is wrong. Secondly, your fixtures ought to be little more than wiring code to call the APIs in your application. If your fixtures are doing significant work, then something is wrong.
In most FitNesse environments the number of fixtures is rather small. For example, there are over two hundred acceptance tests for fitnesse itself, but the number of fixtures in on the order of a dozen, and they are all relatively simple.
Get help on the [email protected] site. The folks there are usually very responsive to questions.
如果您可以使用文本与您的软件进行通信，那么我在过去的项目中使用 expect。
我使用简单的 xUnit 样式标记将框架存储为 XML 文件的测试。然后使用样式表将 xml 文件转换为可执行测试。我最终将测试转换为 Tcl/Expect，但您可以将它们转换为任何内容。事实上，如果您愿意，您可以根据您的需要将它们转换为多种语言。
有几个人善意地提醒我（就像你提醒你可怜的、憔悴的祖父下巴上流着口水一样）我们已经在 21 世纪了，当他们询问我为什么会选择 Tcl 而不是其他一些产品时现代语言。事实证明，为了这种测试的目的，我还没有找到更好的选择。 Tcl 语言在这一领域仍然发挥着重要作用。相信我，我不会有一天醒来并对自己说“我需要一个用每个人都会讨厌的脚本语言实现的测试框架！”
不管你相信与否，我确实在寻找一种工具，任何工具，都具有以下特征：
我并没有打算在家种植它到我所拥有的程度。最初，我查看了已建立的测试框架，例如 DejaGnu 和 android。大多数情况下，它们的功能太多了。它们的功能如此丰富，以至于我认为如果没有大量的预先培训，项目就很难开始使用它们。浏览 DejaGnu 后，我对 Tcl 产生了总体兴趣，并在简要浏览了 < a href="http://wiki.tcl.tk/1502" rel="nofollow noreferrer">tcltest，我差点放弃了。 DejaGnu 和 tcltest 都假设您是高级 Tcl 脚本编写者，我认为我公司里的任何人都不会成为这样的人。此外，我希望测试框架（如果可能）支持 xUnit 类型的测试框架，但这些工具都没有支持。
最终我找到了 TclTkUnit，一个基于 Tcl 的测试框架，是沿着 xUnit 设计的线。只需一个短暂的逻辑飞跃，我就意识到我可以在 Expect 而不是 tclsh 中运行 TclTkUnit 并获得我需要的一切。
随着它最终被更多地使用，我添加了另一个样式表，以便在 Web 浏览器中很好地呈现 xml 文件。测试框架生成了它自己的文档。
在另一个项目中，我们需要一个非常基本的模拟/刺激环境来模拟一个人在我们没有的硬件上投掷开关和按下按钮。只需几个小时就可以将测试框架改造为模拟器。创建该框架需要做一些工作，但我们认为从长远来看它确实带来了好处。我真的相信，创建自己的工具会产生这些不可预见的后果，这就是敏捷社区和敏捷社区中的人们所关注的原因。尤其是 XP 一直都是如此强烈的拥护者。
If you can communicate with your software using text, then I have had success on past projects rolling my own framework using expect.
The framework I cooked up stored tests as XML files, using a simple xUnit style markup. The xml files were then transformed into executable tests using a stylesheet. I ended up transforming the tests into Tcl/Expect, but you could transform them into anything. In fact, if you wanted, you could transform them into multiple languages, depending on your needs.
Several people have kindly reminded me (in the same way you remind you poor dottering grandfather about the drool on his chin) that we are in the 21st century when they inquire why I would choose Tcl over some more modern language. As it turns out, for the purposes of this kind of testing, I haven't yet found a better choice. The Tcl language still kicks butt in this area. Trust me, I didn't wake up one day and say to myself "self, what I need a test framework implemented in a scripting language everyone will hate!"
Believe it or not, I really was looking for a tool, any tool, that had the following characteristics:
I did not set out to home grow this to the extent I have. Initially, I looked at established test frameworks like DejaGnu and android. Mostly they had way too many features. They were so feature laden that I didn't think they would be easy for a project to start using without a lot of up front training. Looking at DejaGnu, got me interested in Tcl in general, and after a brief look at tcltest, I almost gave up. Both DejaGnu and tcltest assume you are an advanced Tcl scripter, which I didn't think anyone at my company ever would be. In addition, I wanted the test framework (if possible) to support an xUnit type of test framework and neither of these tools did.
Eventually I found TclTkUnit, a Tcl based testing framework that is designed along xUnit lines. It was only a short leap of logic to realize I could run TclTkUnit in Expect instead of tclsh and get everything I needed.
As it ended up getting used more, I added another stylesheet to render the xml files nicely in a web browser. The test framework generated it's own documentation.
On another project we needs a very basic sim / stim environment to emulate a person throwing switches and pushing buttons on a piece of hardware we didn't have. It only took a few hours to hack the test framework to function as a simulator. Creating the framework took some work, but we felt that it did pay benefits in the long run. I really believe that these types of unforseen consequences of creating your own tools is why people in the agile community & XP in particular have always been such strong advocates.
我们为 Fitnesse 采用了基于 Fitnesse 但实际上无需代码的方法，使用 GenericFixture（通过 Google 搜索 Anubhava 找到他的 WordPress 网站）。
这使我们能够使用对业务方（而不是技术方）友好的语言创建“可执行的测试叙述”。这种语言在 Generic Fixture 中非常容易定义，几乎不需要编码，被称为 DSL（领域特定语言）。因此，我们可以使用医学术语甚至英语以外的语言来编写测试叙述。基本上我们得到的是将用例转化为可执行的叙述。
我们开始在一个大型项目中使用它（2 年 15 人），并且（到目前为止）似乎有一个美好的未来。
它可以轻松地允许测试驱动开发或开发后创建测试（传统方法）。
它是基于 wiki (Fitnesse) 的，其版本控制和重构功能迄今为止已被证明足够。
如果有人感兴趣，我可以提供更多信息。
最好的问候，
亚里士多德。
We have adopted a Fitnesse-based but practically-code-free approach using GenericFixture (google for Anubhava to find his wordpress site) for Fitnesse.
What this allows us to do is to create "executable test narratives" using a language that is friendly to the business-side (as opposed to the technical-side). This language, which is very easily defined, practically without coding, in Generic Fixture, is called a DSL (domain specific language). So we can write our test narratives using e.g. medical terms or even in a language other than English. Basically what we get is transforming our Use Cases into executable narratives.
We are starting to use it in a large project (15 ppl for 2 years) and it seems (so far) to have a good future.
It easily allows Test Driven Development or test-creation after development (traditional approach).
It is wiki-based (Fitnesse) and its versioning and refactoring funcitonality has proven so far sufficient.
I can give more info if anyone is interested.
best regards,
Aristotelis.
我们也使用 NUnit 等单元测试框架来驱动我们的子系统测试 - 测试并不关心它们是如何运行的。但它没有 Fitnesse 的基于文档的方法。
We use unit-testing frameworks like NUnit to drive our subsystem tests as well - the tests don't care how they are run. It doesn't have fitnesse's document-based approach, though.