摘要:很多朋友都知道，豆腐最近在项目中遇到了技术上的难题，或者说这个难题在现实生活中本身就是存在的。比如当对两个html进行比较时， 如何能够正确地向用户提供 友好的比较结果。举一个很简单的例子。<span>123</span> 和<div>123</div> 在html source 层面是完全不同的字符串，但是对于用户体验来说，这两个字符串是一致的。 再比如<ul><li>First</li><li>Second</li></ul> 和 <li>First</li><li>Second</li> 在显示的时候是完全一致，但是html 确差了很多。 我们可以从技术上向用户解释说， 他们本来就是不一样的，但是这样会吓跑我们的用户。我想了很多办法来解决这个问题，解决方案就是建立一个可配置的配置表， 通过反射建立起一套规则，当出现比较结果和human 体验不一致的时候，就利用这套逻辑进行修正，但是这样的问题就是 头疼医疼 脚疼医脚 ，总是滞后于用户发现问题，就和IE 的补丁一样，虽然可以解决问题，但是永远都是再发现问题以后才去解决。终于有一点，痛下决心，在根子上解决这个问题。 解决这个问题的关键，就是在相同的用户体验的前提下，尽量的将数据源修正为同等比较， 这样的唯一解决方案就是XHTML 了，下一步的问题是，如何进行修正，这个可不是一个小问题。 直道有一天一个很偶然的机会，发现了W3C组织提供的Open Source  的项目Html Tidy,这个Html Tidy 可以帮助我们 对html 字符串进行修正，并做标准化的处理。详细的关于Html Tidy 的信息，大家可以去这个站点， 我也会在后续的Post 中做详细的介绍。如果大家也有兴趣的话，我们可以一起来研究和探讨。 谢谢。...[阅读全文]

摘要:最近在我们的项目中，进行了一次如何进行Test 的大讨论。 大家都知道，Test 分为UnitTest 和 Function Test, 关于Function Test, 我们大家都没有歧义， 认为现阶段使用WatiN 的自动化测试已经能够满足项目的基本需要， 大家的分歧主要就在于如何进行Unit Test.很显然，Unit Test是在测试我们的项目的最小单元， 但是问题是在一个 Data Driven 的项目中， 很多的最小单元都会使用到数据库访问，于是 Unit Test 是否需要Touch DB 就成为了这次讨论的核心问题。 我们主要有两种观点1. 数据库测试也是我们必要的测试一部分 ,因此我们有必要在Unit Test中对物理的数据库访问的函数进行测试。2.我们的测试并不希望去访问数据库，因为我们的Unit Test的测试用例将近 上千， 这样在每次check in 之后， 运行所有的Unit Test 就会不现实持第一种观点的同学认为，既然我们有Daily Build的策略，我们不需要每次的 check in 都触发Unit Test的case, 在daily build 中一起运行Unit Test, Coverage Test 和Function Test,将测试报表发到大家的信箱就可以了。持第二种观点的同学认为，Unit Test是保证代码质量的最低要求，因此需要明每次Check In 都触发Unit Test 并且Unit Test 应该是没有执行次序的， 如果涉及到数据库访问，则必须需要复杂的 Build Script 以保证Unit Test的执行次序。经过差不多一周的lunch discussion 我们基本上同意使用第二种方案。但是第二种方案会带来一些新的挑战，如果进行Unit Test ,那些碰到数据库访问的方法， 或者要调用数据库访问的方法和类该如何测试？在这里，我提出的解决方案是使用NMock 这个Open Source  的项目。 下面简单介绍一下这个 项目, 你可以在http://nmock.org/ 这个地址看到关于这个项目的详细介绍， 我举一个非常简单的例子。我们的项目一般都会分为 数据层， 业务层和 展现层。一个典型的数据层是这样的namespace Q4.Core.Datalayer.Interface{    public interface IUser    {        int UserId { get;set;}        string UserName { get;set;}        string FirstName { get;set;}        string LastName { get;set;}    }}namespace Q4.Core.Datalayer{   ......[阅读全文]