- 浏览: 199666 次
文章分类
- 全部博客 (185)
- A Design Patterns (2)
- B Refactoring (0)
- C Test (2)
- D Software Engineering (0)
- E Other Tech Articles (4)
- F My Blog (0)
- G TechJie forum & QQ group (2)
- H Programmer (6)
- I 杂7杂8 (4)
- J Translations (0)
- [网站分类]1.首页原创精华.NET区(包含架构设计、设计模式)(对首页文章的要求:原创、高质量、经过认真思考并精心写作) (3)
- [网站分类]2..NET新手区(用于发表不合适发表在首页的.NET技术文章,包括小经验、小技巧) (14)
- [网站分类]3.非技术区(技术之外的文章,但不要涉及任何政治内容) (40)
- [网站分类]4.其他技术区 (9)
- [网站分类]5.企业信息化 (0)
- [网站分类]6.读书心得区(技术书籍阅读心得、书籍推荐) (8)
- [网站分类]7.提问区(.NET技术方面的提问) (6)
- [网站分类]8.技术转载区(.NET技术文章转载, 请注明原文出处) (24)
- [网站分类]9.求职招聘区(个人求职、企业招聘) (0)
- [网站分类]GIS技术 (0)
- [网站分类]SharePoint (0)
- [网站分类]博客园.NET俱乐部(俱乐部组织与活动方面的文章) (2)
- [网站分类]软件发布区(发布自己开发的代码、软件) (0)
- [网站分类]网站管理区(网站管理方面的疑问、建议、意见, 寻求管理员帮助) (0)
- [网站分类]业界新闻 (6)
最新评论
-
没有终点:
不懂 lz说的是啥 我太菜了
超简单SVN教程 -
韩悠悠:
超简单SVN教程 -
DraculaW:
orz...如果让他去写书很好奇这个作者会怎么解释vector ...
又见热书讨论《JavaScript征途》 -
gigix:
weiqingfei 写道为什么国内写书的都是烂人?
为什么高 ...
又见热书讨论《JavaScript征途》 -
weiqingfei:
为什么国内写书的都是烂人?为什么高手都不写书?
又见热书讨论《JavaScript征途》
Write test classes per purpose, rather than per class
I've noticed two styles I've used on my last, first TDD, project. The first is from when I was newer, and I would write one, absolute minimum test and make it pass, then move on to another test. Now, still taking small steps, I often find myself writing a complete test, with say five asserts, and then incrementally adding to the method under test to progress past each assert, until all pass. Any comments on this approach?
============
I've done both, and I feel that the flow is better with tiny tests - but I still find myself doing incremental tests from time to time. One technique that I've found helpful in keeping the tiny test approach fluid is use of setup() - and that got easier after Dave Astel's book taught me to write test classes per purpose, rather than per class. So tests that need different setups wind up in different test classes. When I was still in one-test-class-per-class mode, I was more inclined to write bigger test functions, because what belonged in setup was getting duplicated in each test. Utility functions also come in handy - encapsulating the assertions that you want to make more generally. For me, there's kind of a tradeoff between utility functions and one-test-per-purpose, because if I want the utility function to do assertions, then it should belong to a subclass of TestCase, and if I want my test classes to call those functions directly, then they want to subclass my utility class, and that soon becomes more structure than I want in my test classes.
================
One test-class per purpose, and not per class? Please elucidate. What defines a purpose, and how do you organize your tests? Does one class have many purposes, or does one purpose span many classes?
===============
A simplistic, mechanical answer - and one that serves me reasonably well - is that the setup defines the purpose. If I need different setup, that drives me to create a different test class. I don't have Astels' book in front of me, but I do recommend it for its explanation of this, much better than I can do here. My practice is not as absolute as maybe my remarks suggested - sometimes my test classes will include cases with different (inline) setup. But when I see too much of that, or duplicated setup in multiple tests - that's the code asking me to sprout a new test class. Or a utility function, depending. On what, I can't really say.
Well - the tests are never far from the class (same package, suffixed .test), and Eclipse lets me find references. So I never have a problem finding the test class. Regarding naming - take Range, for example. I might have RangeTest, covering contains(), isEmpty(), encompass(), which setup includes a single Range, or a few Ranges for which the functions can be evaluated, plus RangeInteractionTest, which tests intersects(), intersection(), and other - well, Range Interactions. I'd have to look at my code to find real examples; no time right now. But that should give you an idea. Really, though - check out the book.
============
from Dave Astels' Test-Driven Development: A Practical Guide, pp 74-76: Let's begin by considering TestCase. It is used to group related tests together. But what does "related" mean? It is often misunderstood to mean all tests for a specific class or specific group of related classes. This misunderstanding is reinforced by some of the IDE plug-ins that will generate a TestCase for a specified class, creating a test method for each method in the target class. These test creation facilities are overly simplistic at best, and misleading at worst. They reinforce the view that you should have a TestCase for each class being tested, and a test for each method in those classes. But that approach has nothing to do with TDD, so we won't discuss it further. This structural correspondence of tests misses the point. You should write tests for behaviors, not methods. A test method should test a single behavior... ...TestCase is a mechanism to allow _fixture_ reuse. Each TestCase subclass represents a fixture, and contains a group of tests that run in the context of that fixture. A fixture is the set of preconditions and assumptions with which a test is run. It is the runtime context for the test, embodied in the instance variables of the TestCase, the code in the setUp() method, and any variables and setup code local to the test method... ...Instead of using TestCase to group tests for a given class, try thinking about it as a way to group tests that need to be set up in exactly the same way. A measure of how well your TestCase is mapping to the requirements of a single fixture is how uniformly that fixture (as described by the setUp() method) is used by all of the test methods. Whenever you discover that your setUp() method contains code for some of your test methods, and different code for other test methods, consider it a smell that indicates that you should refactor the TestCase into two or more TestCases. Once you get the hang of defining TestCases this narrowly, you will find that they are easier to understand and maintain.
发表评论
-
23个模式中你最想干掉谁?
2006-12-03 17:34 858*两天发了三个首页确实有污染版面之嫌,但是最后这个帖子实在是非 ... -
从零开始学习Webservice
2007-01-15 21:37 978下载附件作为2007技术目标的第一条,学习Webservice ... -
老师生日问题的解答
2007-03-13 23:31 968没有时间整理了,代码效率很低,以后有时间提高,仅供大家讨论:) ... -
关于TDD构造函数(From Maillist)
2007-05-13 14:21 779Frank: 大家好,不知道有没有人能帮我看看这个有些罗嗦的 ... -
MVC & MVP - Martin's "GUI Architectures" series (1) updated on 15 July. 07
2007-05-31 12:14 1005翻译Martin的文章并没有跟人家打招呼,我想他太忙了。翻译文 ... -
超简单SVN教程
2007-07-09 17:38 3541冰融 17:31:06你创建一个库了? 沧浪之水 17:29: ... -
23个模式中你最想干掉谁?
2006-12-03 17:34 749*两天发了三个首页确实有污染版面之嫌,但是最后这个帖子实在是非 ... -
从零开始学习Webservice
2007-01-15 21:37 826下载附件作为2007技术目标的第一条,学习Webservice ... -
老师生日问题的解答
2007-03-13 23:31 766没有时间整理了,代码效率很低,以后有时间提高,仅供大家讨论:) ... -
Write test classes per purpose, rather than per class
2007-03-31 16:52 1097I've noticed two styles I've us ... -
关于TDD构造函数(From Maillist)
2007-05-13 14:21 884Frank: 大家好,不知道有没有人能帮我看看这个有些罗嗦的 ... -
MVC & MVP - Martin's "GUI Architectures" series (1) updated on 15 July. 07
2007-05-31 12:14 1369翻译Martin的文章并没有跟人家打招呼,我想他太忙了。翻译文 ... -
超简单SVN教程
2007-07-09 17:38 1550冰融 17:31:06你创建一个库了? 沧浪之水 17:29: ...
相关推荐
"I decided to write rather than (to) telephone."(我决定写信而不是打电话。)当`rather than`位于句首时,不定式通常不带`to`,如"Rather than allow the vegetables to go bad, he sold them at half price....
**扩容U盘检测工具Udisk Write Test软件UWriteTest** 在数字时代,U盘作为便携式存储设备,被广泛用于数据传输和备份。然而,市场上的U盘质量参差不齐,有些商家为了降低成本,可能会销售所谓的“扩容U盘”,即实际...
PassMark BurnInTest V5.3 Copyright (C) 1999-2008 PassMark Software All Rights Reserved http://www.passmark.com Overview ======== Passmark's BurnInTest is a software tool that allows all the major sub...
该文档介绍了SOA和Heterogeneity中的相关内容,告诉我们什么是Dotci,并详细的介绍了Docker和Dotci的共同应用,在此基础上,简介了Docker和Dotci的常用工具和环境。
We need to model the concept of...We can model parents as instances of the Person class and children as a collection of Person instances,. At least, the Family class should provide the following methods:
Udisk Write Test是一款强大的扩容U盘检测工具。用户可以通过该软件测试U盘是否被奸商扩容。该软件的作用就是通过测试还原U盘容量的真实面目,检测写入数据的完整性。 Udisk Write Test 使用说明: 打开,软件会...
标题中的“test_sd.rar_SD FAT16_SD_TEST_Write On_test_sd.rar_write sd card”表明这是一个与SD卡相关,特别是FAT16文件系统相关的测试项目,用于在SD卡上进行写入操作。描述中提到的“a simple program to write ...
Today, software organizations invest more time and resources in analyzing and testing software as a unit rather than as independent entities. Software engineers have observed that writing testing ...
Write code once, rather than risk copying buggy code Keep unit interfaces small by extracting parameters into objects Separate concerns to avoid building large classes Couple architecture components ...
Write code once, rather than risk copying buggy code Keep unit interfaces small by extracting parameters into objects Separate concerns to avoid building large classes Couple architecture components ...
- "I decided to write rather than (to) telephone." (我决定写信而不是打电话。) - "You rather than I am going to go camping." (是你而不是我要去露营。) 3. **would rather 和 prefer 的用法** - ...
"Write To File Speed Test - 副本_labview_" 是一个专门针对LabVIEW的文件读写速度测试程序,旨在帮助用户了解和优化他们的文件操作性能。 首先,我们需要理解LabVIEW中的文件I/O操作。LabVIEW提供了丰富的文件...
在缓存管理策略中,"Write Back"(回写)和"Write Through"(写通)是两种常见的写操作策略,它们在处理数据更新时有着不同的机制和优缺点。 **Write Back(回写)** Write Back策略是一种非立即写入主存的数据更新...
①定义类的头部 class Pen ②定义类的主体部分,包括变量和方法:变量如colo r,length,price等;方法如Write(),GetPrice()等 ③定义多个构造方法,如Pen(),Pen(参数列表) 2. 定义对象的方法 ①定义公共类Test,则保存...
在该示例中,通过`document.getElementById`获取了具有特定id的元素,并调用`getClass`函数获取其class名为`cs`的子元素,最后通过`document.write`将这些子元素的`innerHTML`输出。 6. `document.write`方法: `...
Read and Write Utility
GPIO,全称General Purpose Input/Output,是通用输入输出接口,广泛应用于嵌入式系统设计中,如微控制器(MCU)和系统级芯片(SoC)。GPIO接口允许硬件开发者控制和监测系统的数字信号,使其能灵活地与其他硬件组件...
Quartus II 使用 Testbench 方法 Quartus II 是 Altera 公司的一款 FPGA 设计软件,Testbench 是一种验证 FPGA 设计的方法。使用 Testbench 方法可以模拟 FPGA 设计的行为,从而验证其正确性。下面是使用 Quartus ...