如何在库中包含单元测试的最佳实践
我正在开发一个名为 as3lib 的 ActionScript 3.0 通用代码库，其中包括核心 API 的多个扩展和一些有用的函数。我已经编写了几个单元测试（使用 FlexUnit）以确保一切正常工作。
在库中组织这些测试的最佳方式是什么？目前，我将所有代码放在 src/ 中，将测试放在 test/ 中但我已经设置了一个辅助 Flex 项目来运行单元测试。当我想运行测试时，我还手动从库中添加和删除测试文件。
我正在做的事情似乎不对。有更好的办法吗？最好是编译的库不包含测试文件，但我不需要两个单独的项目来测试它们。
I'm working on a general code library for ActionScript 3.0 called as3lib which includes several extensions to the core API and some useful functions. I've written several unit tests (using FlexUnit) to make sure everything is working correctly.
What is the best way to organize these tests in the library? Currently, I have all my code in src/ and my tests in test/ but I've set up a secondary Flex project to run the unit tests. I am also manually adding and removing the test files from the library when I want to run the tests.
What I'm doing doesn't seem right. Is there a better way? Preferably one where the compiled library doesn't include the test files but I don't need two separate projects to test them.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
我们在我的公司做这些事情的方式是，我们实际上将这两个文件都包含在源目录下，然后我们有两个使用的应用程序 mxml 文件。一个是测试套件，其中包括单元测试类的所有适当链接，另一个是主应用程序。我们在 src 文件夹内还有两种包结构：一种包结构 com..，另一种为 tests.com... 确保单元测试的所有源代码始终< /em> 在测试包中——这样你就可以只使用一个 SVN 忽略，并且还可以确保你的测试不会与其他项目创建依赖和硬编码的关系。
我们使用两种方法来确保不包含 test.com 源文件。自动构建系统仅引用主应用程序，并且由于仅从 com. 导入，因此 mxmlc.exe 将仅包含主应用程序的文件。在 Eclipse 内部本地构建时，您可以通过单击“调试”旁边的小箭头并滚动到“组织收藏夹”来控制构建方式。当您单击“添加”时，您应该能够选择引用 Application 类的所有根级 .mxml 文件。请务必添加基本应用程序和新的单元测试应用程序文件。然后，当您单击“确定”时，箭头现在允许您作为主应用程序或单元测试框架进行调试。
顺便说一句，我们还使用 FlexUnit 作为我们的测试框架。我喜欢它。
The way we've done these things at my company is that we actually include both under the source directory, and then we have two application mxml files which we use. One is the testing suite, which includes all of the appropriate links to unit-test classes, the other is the main application. We have also have two package structures inside of the src folder: one package structure com.., and another tests.com... Make sure that ALL source code for unit tests are ALWAYS in the tests package -- this way you can use only one SVN ignore, and you can also make sure that your tests do not create dependent and hard-coded relationships with other projects.
There are two ways which we use to ensure that the test.com source files are not included. The automated build system only references the main application, and since that only imports from com., mxmlc.exe will only include the files for the main application. When building locally, inside of eclipse, you can control how things build by clicking on the little arrow next to Debug and scroll to "Organize favorites." When you click "Add", you should be able to select all root level .mxml files which reference the Application class. Be sure to add the base application and the new unit test application file. When you then click "OK", the arrow now allows you to debug either as the main application, or your unit test framework.
As an aside, we also use FlexUnit as our testing framework. I like it.
我所做的与您过去描述的方式类似，但这似乎是 SpringAS 的事情 可以非常方便地从配置中动态添加和删除它们。你尝试过调查一下吗？
I've done it similar to the way you're describing in the past, but it seems like the sort of thing where SpringAS could come in pretty handy for dynamically adding and removing them from the configuration. Have you tried looking into that?
我们的库的顶层有单独的 src 和测试目录。我们的应用程序是库项目的非常薄的包装，因此它们不需要任何测试。我们还有一个 FlexUnit 应用程序项目，用于从 FlexBuilder 运行测试。
我们使用 Maven 作为我们的主要构建系统，Sonatype Flex 插件在构建过程中运行我们所有的单元测试，甚至在我们基于 Linux 的 Continuum 服务器上也是如此。 Maven 默认在“tests”目录中查找测试，这是选择该位置的一个很好的理由。
We have separate src and tests directories at the top level in our libraries. Our applications are very thin wrappers around library projects, so they don't need any tests. We also have a FlexUnit application project, to run the tests from FlexBuilder.
We use maven for our main build system, and the Sonatype Flex plugin runs all our unit tests during the build, even on our linux-based Continuum server. Maven defaults to looking for tests in a 'tests' directory, which was a good justification for picking that location.
我将反其道而行之，并建议为您的测试完全建立一个不同的项目。我相信，一般来说，将测试放在哪里并不重要，只要它是一致的并且在某种程度上是可管理的。然而，对我来说，建立一个单独的测试项目有三个令人信服的理由：
关注点分离。首先，你的库有一个目的，测试有另一个目的。虽然测试需要该库才能运行，但该库对测试没有真正的用途。 请注意，我并不是说测试毫无用处，远非如此。这些测试是为了验证库的运行状况，但在生产环境中，这些测试没有任何作用。
更少的膨胀，更小的文件。测试并不总是微不足道的。但即使它们全部都是，它们仍然会使用磁盘空间。由于测试无论如何都不会在生产环境中使用，因此这是毫无意义的。此外，将测试分离到一个新项目中可以使文件结构更加清晰。
当没有测试时，CI 环境通常更容易设置。
虽然肯定至少可以使用编译器指令解决第二个问题，但当将两者分开要容易得多时，这是不必要的工作。测试可能需要您使用相同名称空间（内部类？）的库或应用程序也不是问题，因为您的测试项目可能会镜像名称空间。显然，这使得命名空间中不能出现名称冲突，但这很简单。
就 Flash Builder 支持而言，将事物分成两个项目非常棒。创建新测试所需要做的就是右键单击您想要测试的任何类，要求创建新测试并确保选择您的测试项目而不是弹出对话框中的当前项目。这确实是我和我的团队成员在进入 TDD 时很难证明编写测试的主要原因，因为刚开始就需要太多的开销。就 IDE 的当前状态而言，它非常简单且有用。
然而，与任何技术一样，也有一些警告。一方面，除非有记录，否则测试是否在不同的项目中并不明显。在同一个项目中进行测试可以有效地解决这个问题。另一方面，通过配置 Maven 或环境中可能拥有的其他依赖管理工具可以轻松解决此问题。另一个问题是，如果您的测试项目中确实有一个镜像库或应用程序的包结构，则同步这些结构会产生一些维护开销。虽然不是一个大问题并且很容易使用脚本解决，但它仍然值得一提。
无论如何，我就是这么做的。
I'm going to go against the flow here and suggest setting up a different project altogether for your tests. I believe that generally it doesn't really matter where you put the tests, as long as it's consistent and somewhat manageable. However, to me there are three compelling reasons for having a separate project for the tests:
Separation of concerns. First, your library has one purpose, the tests have another. While the tests needs the library to function, the library has no real use for the tests. Note that I'm not saying tests are useless, far from it. The tests are there to verify the health of the library but in a production environment the tests serve no purpose.
Less bloat, smaller files. Tests aren't always trivial. But even if they all were, they'd still be using disk space. Since the tests aren't used in a production environment anyway, this is pointless. Also, separating tests into a new project makes the file structure a lot cleaner.
CI environments are generally cleaner to set up when the tests aren't around.
While it's certainly possibly to at least solve the second problem with compiler directives, it's unnecessary work when it's a lot easier to just separate the two. Testing a library or application that may need you to use the same namespace (internal classes anyone?) is also not a problem, since your tests project may mirror the namespaces. Obviously this makes it necessary to not have name collisions in the namespaces, but that's trivial.
In terms of Flash Builder support it's great to separate things into two projects. All you need to do to create a new test is right click whatever class you whish to test, ask to create a new test and make sure you choose your tests project instead of the current in the dialog that pops up. That's really the main reason why me and my team members had a hard time justifying writing tests when we got into TDD, too much overhead just to get started. With the current state of the IDE, it's ridiculously simple and useful.
As with any technique however, there are caveats. For one thing, it's not obvious that the tests are in a different project unless it's documented. Having the tests in the same project effectively sorts that problem. On the other hand, this is easily solved by configuring maven or other dependency management tools you may have in your environment. Another issue is that if you do have a package structure in your tests project that mirrors that of the library or application, there's some maintenance overhead in having those structures synchronized. While not a huge issue and quite easily solved using scripting, it's still worth mentioning.
Anyhow, that's how I do it.