文本文件导入项目中的 TDD
我才刚刚开始，是的，我还没有编写任何测试（我不是原教旨主义者，我不喜欢仅仅因为没有测试就出现编译错误），但我想知道从哪里开始执行一个项目，根据 XML 映射将固定长度的平面文件记录解析为表示所有文件布局的超集的类，然后将类详细信息写入（通过转换）数据库表。
有很多外部因素，我不想嘲笑它们，那么从哪里或如何开始测试这个项目是一个好方法呢？
I'm just starting, and yes, i haven't written any tests yet (I'm not a fundamentalist, I don't like compile errors just because there is no test), but I'm wondering where to get started on doing a project that parses fixed length flat file records according to an XML mapping, into a class that represents the superset of all file layouts, before writing (with transformation) the class details to a DB table.
There are so many external factors, and I don't want to mock them all, so where or how would be a good way to start test driving this project?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
这就是将问题分解为多个部分。一些示例：
尝试为每个类赋予单一职责，确定其依赖项，然后将其注入。在模拟/存根的帮助下，这将允许你单独测试每个类。
It's all about decomposing the problem into parts. Some examples:
Try to give each class a single responsibility, determine its dependencies, and inject those in. That, with the help of mocks/stubs, will permit you to test each class in isolation.
我发现两种技术对于测试基于 IO 的类很有用：
StringReader或MemoryStream并以这种方式提供数据很容易。Assembly.GetManifestResourceStream在执行时获取数据。除了这些一般性观点之外，TrueWill 的建议听起来非常好。如果您可以分解更大的任务，那么为每个单独的部分编写单元测试听起来可能会很容易 - 除了数据库访问之外，这通常是一件痛苦的事情。如果您可以使数据库部分尽可能小，并提供来自另一个易于测试的类的所有数据，那应该会使事情变得更简单。
Two techniques I've found useful for testing IO-based classes:
StreamReaderandStreamrather than filenames. It's easy to create aStringReaderor aMemoryStreamin tests and provide the data that way.Assembly.GetManifestResourceStreamto get the data at execution time.Beyond those general points, TrueWill's advice sounds very good. If you can split up the bigger task, writing the unit test for each individual bit sounds like it'll probably be easy - with the exception of the database access, which is usually a pain. If you can make the database part as small as possible, providing all the data from another easy-to-test class, that should make life simpler.
好吧，您想要进行测试，但不想进行模拟。我相信它让您编写 集成测试 或 验收测试。这意味着您必须在测试中进行大量设置，这可能会使您的测试变得脆弱且难以维护。
我真的建议模拟您的外部依赖项。它将使您的应用程序松散耦合，我相信将来它会更容易维护。另外，您的测试将变得更加易于管理。
有很多 模拟框架 那里可以帮助你。我必须承认，如果您以前从未这样做过，那么就会有一些学习曲线。但我们从事软件开发业务，总是有新的东西需要学习。
如果您决定投入一些时间来学习模拟测试，您可以从 本文。
祝你好运。
Well, you want to do testing but you don't want to mock. I believe that it leaves you to write integration tests or acceptance tests. It means that you have to do a lot of setup in your tests that probably will make your test brittle and hard to maintain.
I would really recommend to mock your external dependencies. It will make your application loosely couple and I believed it's going to be easier maintain in the future. Plus your tests are going to be much more manageable.
There are lot of Mock Frameworks out there that can help you. I have to admit that if you never done that before there's some learning curve. But we are in software development business and there's always something new to learn.
In case you decided to invest some time to learn testing with mock, you can start with this article.
Good luck.