Hello World
Spiga

标签：单元测试

一份用于学习单元测试的案例需求（实现）

2012-02-03 10:44 by 老赵, 1695 visits
摘要：终于把这份实现写完了，比想象中要花时间，尤其是为了可测试性而增加的代码结构。我并没有使用TDD来开发这个类库，依然是先写代码，再写单元测试，测试代码也只关注了代码主体，没有刻意去测试边界情况。一部分原因是其中都是内部实现，可以把握住输入，令一部分原因是这段实现主要是各种交互，而没有复杂的业务逻辑。我个人满足于单元测试而不是测试驱动开发，但如果您是使用测试驱动开发（TDD）甚至传说中的BDD来实现这个方案，那就更好不过了。 阅读全文

使用Mono.Cecil解决无法Mock非虚方法和密闭类的问题

2012-01-12 14:50 by 老赵, 1129 visits
摘要：之前我在微博上抱怨单元测试会让代码中的接口数量激增，有些同学回复说，这是因为在C#里只能Mock接口，如果是Java的话便可以Mock普通类。不过其实在Mock实现方面，C#和Java没有任何区别，只不过C#的成员默认“非虚”而已，因此无法使用继承后重载的方式实现Mock行为。我不喜欢默认的虚方法，但我也十分不愿意为了“单元测试”这个与具体功能无关的角度而破坏设计本意。幸好，我们可以用Mono.Cecil在单元测试执行之前，将目标程序集里的所有方法修改为虚方法，并去除所有密闭标记，这样遍可以轻而易举的解决无法Mock的问题了。 阅读全文

求助：一份用于学习单元测试的案例需求

2012-01-07 07:23 by 老赵, 2080 visits
摘要：一直熟知单元测试的重要性，也算是了看了几本这方面的经典书籍，但是真开始上手的时候总会遇到各种各样的坎。例如，为什么总感觉自己的单元测试之间有较多的重合，为什么每个单元测试都要准备那么多依赖？有的说法是，这意味着代码设计不够好，单元测试也有问题，或者说没有使用TDD的缘故，等等。但是，现实开发过程中在这方面也颇感无力。前段时间在微博上咨询了几个问题，感觉收获不大，这次干脆整理一份需求，仔细认真向高手学习一下代码设计，单元测试，甚至测试驱动开发的方式吧。我也会准备一些礼物来感谢一部分同学的帮助。 阅读全文

我的TDD实践：可测试性驱动开发（下）

2009-10-19 00:48 by 老赵, 16746 visits
摘要：在上一篇文章里，我谈到自己在采用传统TDD方式进行开发时感到有些尴尬，最后不得不放弃这种先写测试再写代码最后重构的方式。不过我还是非常注重单元测试的实践，慢慢发现自己的做法开始转向另一种TDD方式，也就是“可测试性驱动开发”。简单的说，我现在采取的做法是，先开发，再测试，一旦发现产品代码不太容易测试，则将其重构为容易测试的代码。我发现，这种时刻注重可测试性的开发方式，其最终也能够得到质量较高的代码。上次谈的比较理论，而这次我便通过一个简单功能的开发过程，来表现我的思维方式及常用做法。 阅读全文

我的TDD实践：可测试性驱动开发（上）

2009-10-15 05:34 by 老赵, 17983 visits
摘要：TDD（测试驱动开发，Test Driven Development）是重要的敏捷实践之一，它的基本原理是用测试来带动开发，先写测试代码，再写开发代码，最后重构。许多TDD推广和实践者认为，这种方式易于带来高质量的代码。而如今，TDD也慢慢有了Test Driven Design，也就是测试驱动设计的意味。也就是说，它更像是一种设计方式了。这些理论我很愿意相信，也很支持，但是从实际角度来说，我还是较难接受正统的TDD行为。不过，我也在实际开发过程中总结出……怎么说呢，应该说是更适合我自己的实践方式，在此希望能和大家交流一下。 阅读全文

与protected成员有关的单元测试方式

2009-08-28 09:33 by 老赵, 4129 visits
摘要：protected是一个有趣而有用的修饰符，它把方法的访问成员严格限制在自身或自己的子类身上。换句话说，在使用过程中，protected成员对外部是开放的（因为其他类可以通过继承来使用该成员），又是封闭的（不是自身或子类的一切成员都无法访问）。而对于单元测试来说，protected成员又是尴尬的，因为它的“开放”意味着我们必须对它进行单元测试，而“封闭”又阻碍了我们在单元测试中涉及protected成员。 阅读全文

类中的internal成员可能是一种坏味道

2009-08-26 08:54 by 老赵, 5124 visits
摘要：最近除了搞ASP.NET MVC之外，也在思考一些编程实践方面的问题。昨天在回家路上，忽然对一个问题产生了较为清晰的认识。或者说，原先只是有一丝细微的感觉，而现在将它和一些其他的方面进行了联系，也显得颇为“完备”。这就是问题便是：如何对待类中internal成员。我现在认为“类中的internal成员可能是一个坏味道”，换句话说，如果您的类中出现了internal的成员，就可能是设计上的问题了。 阅读全文

为什么是HttpContextBase而不是IHttpContext

2009-08-21 07:15 by 老赵, 4423 visits
摘要：由于HttpContext很难进行Mock，因此为了提高可测试性，微软随ASP.NET MVC发布了一个“抽象包”，专门用于对HttpContext及其相关组件进行抽象。不过在Preview 1版本中，这些抽象都是一个个接口，如IHttpContext，IHttpRequest等等。而在下一个版本中，立即就成为了一个个抽象类，如HttpContextBase，HttpRequestBase。现在我打算从“使用”角度来谈一下，为什么这里的确应该用抽象类而不是接口。 阅读全文

在单元测试时指定HttpContext的各种Path

2009-08-21 02:02 by 老赵, 4546 visits
摘要：设置HttpContext中各种Path一直是个问题，因为被测试的方法可能用到各种Path中的任何一个，而各种Path之间有一定关联，如果我们完全手动设置Mock对象的话会是一个浩大的工程。还好，这个问题还算容易解决。 阅读全文

DefaultControllerFactory不是线程安全的

2009-08-18 08:07 by 老赵, 4305 visits
摘要：由于项目需要，刚才打算为ASP.NET MVC应用程序增强ControllerFactory的功能，因此翻出了ASP.NET MVC的源代码开始阅读其DefaultControllerFactory。代码不多，很容易理解，不过读着读着便发现了问题，因为我发现DefaultControllerFactory不是线程安全的。 阅读全文

辅助方法不嫌多

2009-04-12 11:25 by 老赵, 20747 visits
摘要：在开发项目过程中，总是会出现大量的辅助方法，例如字符串处理，代码检验，格式输出等等。如果您发现自己在多次编写类似的代码，可能就要想着如何把这些代码进行提取，变成辅助方法（亦或是类库甚至框架，关于这方面粒度问题在此不作讨论）。辅助方法的作用除了遵循DRY原则之外，也能让代码更容易编写，更为清晰，可读性也能更好——而且只要您“去做”，就会发现要得到这些好处并不困难。 阅读全文

尽可能摆脱对HttpContext的依赖

2009-03-09 01:17 by 老赵, 7612 visits
摘要：我们继续《ASP.NET MVC单元测试最佳实践》，今天主要谈论HttpContext的依赖问题。简单说来：虽然已经可以对HttpContext进行Mock（这点增强了可测试性），但是过度依赖HttpContext对于单元测试来说也是一个伤害。这是HttpContext对象的天性所致：它实在太复杂了。因此，我们的代码要尽可能减少对HttpContext的依赖。 阅读全文

对ASP.NET MVC项目中的视图做单元测试

2009-02-24 17:01 by 老赵, 9756 visits
摘要：说到ASP.NET MVC，我们似乎始终都在关注对于Controller的测试，那么我们该如何对视图进行独立的单元测试呢？ 阅读全文

ASP.NET MVC单元测试最佳实践

2009-02-23 01:07 by 老赵, 10163 visits
摘要：我对于微软的一个特点时常呈一种否定态度，那就是因为它往往为了“显摆”自己的技术而向外界展现出一种“飘渺的美好”愿景。例如WebForm推出时铺天盖地的“拖拽”风潮，看似精彩却迷人双眼。这是我在上周“.NET技术大会”上的主题Session。先提供这次Session内容的PPT和演示吧，在接下来的一段时间内，我会陆续分析这次课程的内容。希望大家能够尽可能地把东西给“用好”，而不仅仅是得到表面上的正确结果。 阅读全文
1
使用Live Messenger联系我