TDD - 在空项目中创建一个新类,以使添加的依赖项变得明确

发布于 2024-12-01 20:00:47 字数 270 浏览 0 评论 0原文

使用 TDD,我正在考虑为我创建的每个新类创建一个(废弃的)空项目作为测试工具/容器。所以它存在于一个小小的私人泡沫中。

当我有依赖项并且需要从更广泛的项目中获取其他内容时,我必须做一些工作才能将其添加到我的干净项目文件中,并且我被迫考虑这种依赖项。假设我的班级有一个单一的责任,那么我不应该做太多这样的事情。

另一个好处是几乎即时的编译/测试/编辑周期。

一旦我对课程感到满意,我就可以将其添加到主项目/解决方案中。

以前有人做过类似的事情吗?或者这太疯狂了?

Using TDD, I'm considering creating an (throw-away) empty project as Test-harness/container for each new class I create. So that it exists in a little private bubble.

When I have a dependency and need to get something else from the wider project then I have to do some work to add it into my clean project file and I'm forced into thinking about this dependency. Assuming my class has a single responsibility then I ought not to have to do this very much.

Another benefit is an almost instant compile / test / edit cycle.

Once I'm happy with the class, I can then add it to the main project/solution.

Has anyone done anything similar before or is this crazy?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

北渚 2024-12-08 20:00:48

我参加过使用 Endeavour 的演示。他们高度依赖的概念之一是解耦,正如您所建议的:

  • 在单独的解决方案中提供服务并拥有自己的测试工具

Endeavor 简而言之是一个强大的 VS 开发环境/插件,有助于归档这些东西。在许多其他内容中,它还挂钩/创建来自 SourceSafe 的夜间构建,以定义正在构建的 dll 并将其放置在共享文件夹中。

当您创建依赖于其他服务的代码时,您不会引用 VS 项目,而是引用共享文件夹中已编译的 DLL。

通过这样做,KLE 建议的一些缺点得到了解决:

  • 取决于您的代码的项目引用 DLL 而不是您的项目(构建时间获胜)
  • 当您的项目构建失败时,它不会破坏集成;它们依赖于一个 DLL,该 DLL 在上次工作构建中仍然可用
  • 所有类可见 - 不

中间立场:

  • 您真的必须考虑依赖性,而不是在“简单”设置中。
  • 仍然需要时间,

但当然也有一个缺点:

  • 它不容易检测到循环依赖,

我目前正在思考如何在不完全安装 Endeavor 的情况下实现此设置的好处,因为它是一个相当庞大的产品,真的很多(你们并不都需要)。

I have been to a presentation for using Endeavour. One of the concepts they depended highly upon was decoupling as you suggest:

  • service in seperate solution with its own testing harness

Endeavour is in a nutshell a powerfull development environment / plugin for VS which helps archieving these things. Among a lot of other stuff it also hooks into / creates a nightly build from SourceSafe to define which dll's are building and places those in a shared folder.

When you create code which depends on an other service you don't reference the VS project but the compiled DLL in the shared folder.

By doing this a few of the drawbacks suggested by KLE are resolved:

  • Projects depending on your code reference the DLL instead of your project (build time win)
  • When your project fails to build it will not break integration; they depend upon a DLL which is still available from last working build
  • All classes visible - nope

Middle ground:

  • You REALLY have to think about dependency's, more then in 'simple' setups.
  • Still costs time

But ofcourse there is also a downside:

  • its not easy to detect circular dependency's

I am currently in the process of thinking how to archieve the benefits of this setup without the full-blown install of Endeavour because its a pretty massive product which does really much (which you won't all need).

筱武穆 2024-12-08 20:00:47

我一般没有这样做,创建一个空项目来测试新类,尽管如果我不想修改编辑器中的当前项目,则可能会发生这种情况。

优点可能是:

  • 确保不要修改主项目,或者意外提交
  • 依赖项是没有的,当然

缺点可能是:

  • 花费一些时间......
  • 一旦您想在主项目上添加一个依赖项,您立即获取该项目中的所有类...不是您想要的
  • 考虑依赖项是常见的,我们通常不需要一个空项目来执行
  • 某些工具检查您的项目依赖项以验证它们遵循一组规则,这可能是更好地使用这些(因为这不仅可以在启动时使用类,但也稍后)。
  • 私人泡沫概念也可以通过 import 语句找到。
  • 当前机器上的当前开发环境已经为您提供了超快的操作...如果没有,您可以对此做一些事情(告诉我们更多...)
  • 如果可以,您需要将您的主要项目和测试复制到常规项目中班级。这可能会花费您的时间,特别是当包可能不够时(在您的早期情况下可能是最简单的,因为您的项目是空的,但对于以后的常规项目来说足够了)。

总的来说,恐怕这不会节省时间......:-(

I have not done this in general, create an empty project to test a new class, although it could happen if I don't want to modify the current projects in my editor.

The advantages could be :

  • sure not to modify the main project, or commit by accident
  • dependencies are none, with certaintly

The drawbacks could be :

  • cost some time ...
  • as soon as you want to add one dependency on your main project, you instantly get all the classes in that project ... not what you want
  • thinking about dependencies is usual, we normally don't need an empty project to do so
  • some tools check your project dependencies to verify they follow a set of rules, it could be better to use of those (as that could be used not only when starting a class, but also later on).
  • the private bubble concept can also by found as import statements.
  • current development environments on current machines already give you extra-fast operations ... if not, you could do something about it (tell us more ...)
  • when ok, you would need to copy to your regular project your main and your test class. This can cost you time, especially as the package might not be adequate (simplest possible in your early case because your project is empty, but adequate to your regular project later).

Overall, I'm afraid this would not be a timesaver... :-(

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文