博客园_gossip

AspnetMvc实现无刷新省市联动功能

2012-05-26T07:51:00Z

1、Control层
/// <summary>
/// action方法根据省份编号返回json形式的城市信息
/// </summary>
/// <param name="p">省份编号</param>
/// <returns></returns>
public ActionResult GetCityList(string p)
{
;
IList<City> cityModelList =//根据省份编号返回城市信息
var pList = new SelectList(cityModelList, "CityId", "CityName");

return Json(pList, JsonRequestBehavior.AllowGet);
}

//绑定省份信息
public void BindProvince(string defaultText = "请选择", string defaultValue = "")
{
var dt =// 省份信息
IList<SelectListItem> items = new List<SelectListItem>();
items.Add(new SelectListItem { Text = defaultText, Value = "", Selected = true });
foreach (var dr in dt)
{
items.Add(new SelectListItem { Text = dr.ProvinceName, Value = dr.ProvinceCode });
}
this.controller.ViewData["Province"] = items;
this.controller.ViewData["ddlProvince"] = defaultValue ?? string.Empty;
}
//绑定省市信息
public void BindCity(string provinceId, string defaultText = "请选择", string defaultValue = "")
{
IList<SelectListItem> items = new List<SelectListItem>();
if (provinceId == string.Empty)
{
items.Add(new SelectListItem { Text = defaultText, Value = defaultValue });
}
else
{
var dt = //根据省份编号获取城市信息
foreach (var dr in dt)
{
items.Add(new SelectListItem { Text = dr.CityName, Value = dr.CityId });
}
}

this.controller.ViewData["City"] = items;
this.controller.ViewData["ddlCity"] = defaultValue ?? string.Empty;
} 2、View层

<script src="@Url.Content("~/Scripts/provinceCity.js")" type="text/javascript"></script>

<div class="editor-label">
            省份城市
        </div>
        <div>
            @Html.DropDownList("ddlProvince", ViewData["Province"] as IEnumerable<SelectListItem>)
            @Html.DropDownList("ddlCity", ViewData["City"] as IEnumerable<SelectListItem>)
            @Html.ValidationMessageFor(model => model.CityId)
        </div>


    //隐藏字段用于在js调用，设置url路径 
    @Html.Hidden("GetCityList", Url.Action("GetCityList", "Enterprise")) 
3、Js代码
     $(document).ready(function () {
 
    $("#ddlProvince").change(function () { getCity($(this).val()); });
 
    function getCity(provinveCode) {
        $("#ddlCity").html(""); //清空
 
        $.ajax({
            type: "GET",
            url: $("#GetCityList").val(),
            data: "p=" + provinveCode + "&date=" + new Date(),
            dataType: "json",
            success: function (json) {
                if (json.length > 0) {
                    for (var i = 0; i < json.length; i++) {
                        $("#ddlCity").append("<option value='" + json[i].Value + "'>" + json[i].Text + "</option>");
                    }
                } else {
                    $("#ddlCity").append("<option value=''>请选择</option>");
                }
            },
            error: function (data) {
                alert(data);
            }
 
        });
    }
});

本文链接

使用Moq模拟AspnetMvc中的Request.Form

2012-05-26T07:27:00Z

1、比如Request.Form["ddlType"]为control中需要模拟的内容

2、在单元测试中调用的代码（使用的是VS2010自带的单元测试框架）

本文链接

配置文件操作类

2012-05-23T06:14:00Z

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Xml;

namespace ConsoleApplication1
{
/// <summary>
/// 配置文件工具类
/// </summary>
public static class ConfigUtil
{
/// <summary>
/// 修改Config配置文件的值
/// </summary>
/// <param name="filePath"></param>
/// <param name="key"></param>
/// <param name="newValue"></param>
public static void SetAppSettingsExe(string filePath, string key, string newValue)
{
try
{
var doc = new XmlDocument();
doc.Load(filePath);

doc.SelectSingleNode("/configuration/appSettings/add[@key='" + key + "']").Attributes["value"].Value = newValue;
doc.Save(filePath);
doc.Load(filePath);
doc = null;
}
catch (Exception ex)
{
throw ex;
}
}

/// <summary>
/// 获取Config配置文件的值
/// </summary>
/// <param name="filePath"></param>
/// <param name="key"></param>
public static string GetAppSettingsExe(string filePath, string key)
{
try
{
var doc = new XmlDocument();
doc.Load(filePath);
return doc.SelectSingleNode("/configuration/appSettings/add[@key='" + key + "']").Attributes["value"].Value;
}
catch (Exception ex)
{
throw ex;
}
}

/// <summary>
/// 修改vshost.exe.Config配置文件的值
/// </summary>
/// <param name="key"></param>
/// <param name="value"></param>
public static void SetAppSettingsVshostExe(string key, string value)
{
try
{
//vshost.exe.Config
var doc = new XmlDocument();
doc.Load(AppDomain.CurrentDomain.SetupInformation.ConfigurationFile);

doc.SelectSingleNode("/configuration/appSettings/add[@key='" + key + "']").Attributes["value"].Value = value;

doc.Save(AppDomain.CurrentDomain.SetupInformation.ConfigurationFile);
}
catch (Exception ex)
{
throw ex;
}
}

/// <summary>
/// 获取vshost.exe.Config配置文件的值
/// </summary>
/// <param name="key"></param>
/// <returns></returns>
public static string GetAppSettingsVshostExe(string key)
{
try
{
var doc = new XmlDocument();
doc.Load(AppDomain.CurrentDomain.SetupInformation.ConfigurationFile);
return doc.SelectSingleNode("/configuration/appSettings/add[@key='" + key + "']").Attributes["value"].Value;
}
catch (Exception ex)
{
throw ex;
}
}
}
}

调用：

ConfigUtil.SetAppSettingsVshostExe("aa123", "你们");
var v = ConfigUtil.GetAppSettingsExe(@"E:\项目\ConsoleApplication1\app.config", "aa");
var v2 = ConfigUtil.GetAppSettingsVshostExe("aa");
ConfigUtil.SetAppSettingsExe(@"E:\项目\ConsoleApplication1\app.config", "aa", "马");

本文链接

软件工程师在外企学什么？

2012-05-21T04:10:00Z

原文链接：http://blog.csdn.net/hzliyun/article/details/7564096。

我在Motorola工作了近6年（注：在这期间我经历了Motorola拆分成Motorola Solutions和Motorola Mobility，以及Motorola Solutions将网络部门卖给NSN，期间我所在团队的企业文化和工作环境一直沿用的是原Motorola的），经历了从开发工程师到架构师的成长历程，在此分享一下软件工程师在Motorola这样的外企应学些什么。

首先，由于外企的工作语言是外语，因此掌握外语是必须的。在Motorola这样的外企工作，英语不光要求会看和写，而且要听和说都行。外语对于一线工程师来说要求相对弱一点，因为除了出国和平时与外国同事开会外运用听和写技能的机会少得多。由于架构师这样的职位经常要与国外的同事沟通，对英语的要求就高多了，甚至要做到能用英语去争论。对于希望进入外企的工程师来说，早点练好外语会取得一定的优势，除了能争取到更多的出国机会外，还容易在外国同事面前展示自己。可以毫不夸张地说，英语水平决定了在外企职业发展的“天花板”。

其次，在外企得学习西式沟通。与中式沟通的含蓄不同的是，西式的沟通更加的直接，更加讲究逻辑。在与美国同事打交道的过程中我发现，工作进展与原计划出现偏差并不是什么可怕的事，你只要能直接地告诉他为什么会出现这样的偏差，逻辑能讲得通就不会是问题。另外，外国同行很喜欢我们问问题，他们最害怕的是我们没有问题，一声不吭。由于中国工程师在表达方面表现得不积极，使得我们有时给人的感觉是“难以琢磨”。国人的这种表现，与英语水平有一点关系，但我觉得更多是因为我们缺乏沟通的意识。

再次，学习专业做事是重中之重。由于西方人做事更加的讲逻辑和规则，因此他们做事通常会显得更专业，这与国人的“只要将事情做出来”的思想形成很鲜明的反差。专业做事体现在几个方面。其一，使用合适的工具。国人做事更多的是不管什么事都用“榔头”去做，与之不同的是外国同行会使用各种合适的工具，这一点美国和俄罗斯的同事明显高于我们，他们的技能多元化水平比我们高。其二，文档化。西方的同事更具“人人为我，我为人人”的精神，因此他们更注重通过文档的方式将所碰到的问题和解决方案记录下来与人分享。相比之下，中国的工程师更多的是采用“小金库”的形式，分享起来有的还遮遮掩掩。将知识和经验文档化需要的不只是意识，还对写作能力做了更高的要求。其三，遵守和改进流程。外国同事相对“死脑筋”，他们做事很看重流程。一说到流程国人的感觉很可能是反感，因为我们做事更加主张“无政府主义”、“凡事只要能做完就行了”，这种思想在外企很容易碰壁。

又次，学习流程不可小视。有同仁可能会想“流程有什么好学的，跟着做一遍不就会了吗？”此言差矣！如果关注流程外在的“形”会认为它很简单，如果关注“形”背后的“神”你会发现其中的知识非常丰富，蕴涵了外企是如何运作一个大型研发项目的。流程的好处，不只是引导我们做完事，更是规范我们的行为和帮助培养工作习惯，这一点我相信国人相对缺乏深刻的认识。如果在外企工作但却没有深刻地认识流程，那我会对你说“你白在外企干过了！”

本文链接

Moq基础教程

2012-05-16T02:03:00Z

1 基础概念

集中精力开发业务逻辑部分，而不想在数据层上花费太多时间，这时，可以通过Mock对象来模拟数据层，而不必去为数据连接，CRUD，Mapping等等去做太多的事，而又可以使业务测试可以进行下去

2 教程及下载地址

http://code.google.com/p/moq/

http://www.codethinked.com/beginning-mocking-with-moq-3-part-1

http://www.cnblogs.com/jams742003/archive/2010/03/02/1676215.html

3 一个Demo

//接口
public interface ICustomer

{

void AddCall();

string GetCall();

string GetCall(string strUser);

}

var customer = new Mock<ICustomer>(); //建立Mock对象

//设置mock调用行为

customer.Setup(p=>p.AddCall());

customer.Setup(p => p.GetCall()).Returns("phone:89898789");

customer.Setup(p => p.GetCall("Tom")).Returns("Hello");

//使用mock调用方法

customer.Object.AddCall();

Assert.AreEqual("phone:89898789", customer.Object.GetCall());

Assert.AreEqual("Hello", customer.Object.GetCall("Tom"));

4 功能点介绍

4.1 带有引用或输出参数的方法

string GetAddress(string strUser, out string Address);

string GetFamilyCall(ref string strUser);

var customer = new Mock<ICustomer>();

var outString="oo";

customer.Setup(p => p.GetAddress("", out outString)).Returns("shijiazhuang");

customer.Setup(p => p.GetFamilyCall(ref outString)).Returns("xx");

4.2 调用方法时抛出异常

方法：void ShowException(string str);

测试：

var customer = new Mock<ICustomer>();

customer.Setup(p => p.ShowException(string.Empty))

.Throws(new Exception("参数不能为空！"));

customer.Object.ShowException("");

4.3 调用时赋值

方法：void AddCall();

Mock测试：

var customer = new Mock<ICustomer>();

int iCount = 0;

customer.Setup(p => p.AddCall()).Callback(()=>iCount++);

Assert.AreEqual(0, iCount);

customer.Object.AddCall();

Assert.AreEqual(1, iCount);

customer.Object.AddCall();

Assert.AreEqual(2, iCount);

customer.Object.AddCall();

Assert.AreEqual(3, iCount);

4.4 Is<T>：匹配确定的给定类型

customer.Setup(x => x.SelfMatch(It.Is<int>(i => i % 2 == 0))).Returns("1");

方法SelfMatch接受int型参数，当参数为偶数时，才返回字符串1。

4.5 IsAny<T>：匹配给定的任何值

customer.Setup(p => p.SelfMatch(It.IsAny<int>())).Returns((int k) => "任何数：" + k);

方法SelfMatch接受int型，且任何int型参数都可以，然后返回："任何数：" + k。

这里说明一下Returns方法：

Returns(Func<TResult>)

Returns<T>(Func<T,TResult>)

Returns<T1,T2>(Func<T1,T2,TResult>)

Returns<T1,T2,T3>(Func<T1,T2,T3,TResult>)

Returns<T1,T2,T3,T4>(Func<T1,T2,T3,T4,TResult>)

Returns(TResult)

4.6 IsInRange<T>：匹配给定类型的范围

customer.Setup(p => p.SelfMatch(It.IsInRange<int>(0, 10, Range.Inclusive)))

.Returns("10以内的数");

方法SelfMatch接受int型，且当范围在[0,10]时，才返回10以内的数

其中，这个方法，带有一个包含与排除开关。

4.7 IsRegex<T>：正则匹配

customer.Setup(p => p.ShowException(It.IsRegex(@"^\d+$")))

.Throws(new Exception("不能是数字"));

4.8 设置属性

public class Customer

{

public virtual int Unid { get; set; }

public virtual string Name { get; set; }

}

测试

var customer = new Mock<Customer>();

customer.Setup(p => p.Name).Returns("Tom");

customer.SetupProperty(p => p.Name, "tt");

4.9 Callbacks回调函数

当执行某方法时，调用其内部输入的（Action）委托

看它的5种重载：

Callback(Action)

Callback<T>(Action<T>)

Callback<T1, T2>(Action<T1, T2>)

Callback<T1, T2, T3>(Action<T1, T2, T3>)

Callback<T1, T2, T3, T4>(Action<T1, T2, T3, T4>)

这个方法调用其内部输入的Action委托，Aciton<T>有5种重载，所以这里的Callbacks有5种重载。

以第二个为例：

它的定义为：

ICallbackResult Callback<T>(Action<T> action)

这个表示一个输入参数，

var customer = new Mock<ICustomer>();

customer.Setup(p => p.GetCall(It.IsAny<string>()))

.Returns("方法调用")

.Callback((string s)=>Console.WriteLine("ok"+s));

customer.Object.GetCall("x");

4.10 Verify 验证

用于测试mock对象的方法或属性是否被调用执行。当不需要测试结果时用到

重载很多：

Verify()

Verify(Expression<Action<T>>)

Verify<TResult>(Expression<Func<T, TResult>>)

Verify(Expression<Action<T>>, Times)

Verify(Expression<Action<T>>, String)

Verify<TResult>(Expression<Func<T, TResult>>, Times)

Verify<TResult>(Expression<Func<T, TResult>>, String)

Verify(Expression<Action<T>>, Times, String)

Verify<TResult>(Expression<Func<T, TResult>>, Times, String)

用其中三个举例

第一个：Verify()，定义为：

public void Verify()

测试

public void TestVerify()

{

var customer = new Mock<ICustomer>();

customer.Setup(p => p.GetCall(It.IsAny<string>()))

.Returns("方法调用")

.Callback((string s) => Console.WriteLine("ok" + s))

.Verifiable();

customer.Object.GetCall("调用了！");

customer.Verify();

}

把Mock对象中的GetCall方法设置为可证实的（Verifiable()），

如果不调用粗体部分语句，那么customer.Verify()执行就不能通过。这个方法很有用。

第二个：Verify(Expression<Action<T>>)，定义为：

public void Verify(Expression<Action<T>> expression)

customer.Verify(p => p.GetCall("call"));

如果没有调用且输入call字串的参数，则失败。

第三个：Verify(Expression<Action<T>>, Times, String)

定义：

public void Verify( Expression<Action<T>> expression,

Times times,

string failMessage

)

这个比上一个多了两个参数，一个用于表示调用次数相关描述，一个用于失败的时打印信息

customer.Setup(p => p.GetCall(It.IsAny<string>()))

.Returns("方法调用")

.Callback((string s) => Console.WriteLine("ok" + s))

.Verifiable();

customer.Object.GetCall("call");

customer.Verify(p => p.GetCall("call"),

Times.AtLeast(2),"至少应被调用2次");

当GetCall方法被调用最少2次（且参数为call）时，测试成功。

方法中Times是个Times类类型，它有多个方法：

AtLeast

AtLeastOnce

AtMost

AtMostOnce

Between

Exactly

Never

Once

可以从语义上理解它们各自是什么意思，例如：AtLeast的定义为：

public static Times AtLeast(

int callCount

)

4.11 VerifyAll 验证

在使用Verify方法时，只有被标记为可证实的（.Verifiable()）的才可以验证。

但VerifyAll会验证所有的调用：

customer.Setup(p => p.GetCall(It.IsAny<string>()))

.Returns("方法调用")

.Callback((string s) => Console.WriteLine("ok" + s));

customer.Object.GetCall("call");

customer.VerifyAll();

4.12 Mock<T> Class

public class Mock<T> : Mock

where T : class

这的构造方法：

Mock<T>()

Mock<T>(MockBehavior)

Mock<T>(array<Object>[])

Mock<T>(MockBehavior, array<Object>[])

Mock的泛型实现类，它有很多方法和属性。这里一一列举。

（一）方法

（1）As<TInterface>方法

为mock添加接口实现（mock），可以给它指定设置。

在mock对象的属性（或方法）首次使用之前才有效。且，参数只能是接口。

定义：

public virtual Mock<TInterface> As<TInterface>()

where TInterface : class

示例：

两个接口：

其中的Icustomer接口还是前几篇中用到的，这里添加一个Iorder接口：

public interface IOrder

{

string ShowTitle(string str);

}

Mock测试：

var customer = new Mock<ICustomer>();

customer.Setup(p => p.GetCall()).Returns("方法调用");

customer.Object.GetCall();

var order=customer.As<IOrder>();

order.Setup(p => p.ShowTitle(It.IsAny<string>())).Returns("ok");

Assert.AreEqual("ok",order.Object.ShowTitle(""));

这个将出现异常，因为在As之前，已经对GetCall进行了调用。

（2）SetUp方法

为模拟的对象中的方法指定设置，它有两个重载：

Setup(Expression<Action<T>>)

Setup<TResult>(Expression<Func<T,TResult>>)

从两个委托可以知道，这两个一个是为没有返回值的方法设置，一个是对有返回值的方法设置

public void TestSetUp()

{

var customer = new Mock<ICustomer>();

customer.Setup(p => p.AddCall())

.Callback(()=>Console.WriteLine("没有返回值"));

customer.Setup(p => p.GetCall(It.IsAny<string>()))

.Returns("ok")

.Callback((string q) => Console.WriteLine("有返回值"));

customer.Object.AddCall();

customer.Object.GetCall("");

}

本文链接

NInject注入方式

2012-05-15T04:14:00Z

　Ninject官方网址为：http://www.ninject.org/ 。

类的定义

private IWeapon _weapon;

    //构造函数注入

    [Inject]

    public Samurai(IWeapon weapon)

    {

        _weapon = weapon;

    }

    //属性函数注入

    [Inject]

    public IWeapon Weapon

    {

        get

        {

            return _weapon;

        }

        set

        {

            _weapon = value;

        }

    }

    //方法函数注入

    [Inject]

    public void Arm(IWeapon weapon)

    {

        _weapon = weapon;

    }

    //字段函数注入

    [Inject]

    private IWeapon _weapon;

    public void Attack(string target)

    {

        _weapon.Hit(target);

    }

添加绑定关系(可创建多个Module）
public class WarriorModule : NinjectModule
{
public override void
Load()
{
Bind<IWeapon>().To<Sword>();
Bind<Samurai>().ToSelf();
}
}

构造函数依注入(只能在一个构造函数上使用Inject)
IKernel kernal = new StandardKernel(new WarriorModule());
//Samurai s = new
Samurai(kernal.Get<IWeapon>()); // 构造函数注入
Samurai s =
kernal.Get<Samurai>();
s.Attack("enemy");

属性注入
IKernel kernal = new StandardKernel(new
WarriorModule());

Samurai s = new Samurai() { Weapon =
kernal.Get<IWeapon>() };// 属性注入

s.Attack("enemy");

方法注入
IKernel kernal = new StandardKernel(new WarriorModule());
Samurai s = new
Samurai();
s.Arm(kernal.Get<IWeapon>()); // 方法注入
s.Attack("enemy");

字段注入

new

需将Samurai类中字段_weapon修饰符改为public才可以访问

enemy

本文链接

notepad++ 使用技巧

2012-05-08T10:20:00Z

以下以6.1.2中文版(免安装版)为例说明：

软件下载地址：http://notepad-plus-plus.org/download/v6.1.2.html

设置软件语言：设置—>首选项—>常用

设置双击关闭标签：设置—>首选项—>常用—>标签栏

显示行号：设置—>首选项—>编辑

ASCII码字符列表：编辑—>Character Panel

剪切板历史：编辑—>Clipboard History

书签：搜索—>书签 (F2：上一书签 Shift+F2：下一个书签）

自动换行：视图—>自动换行

左侧显示已打开的文件列表：设置—>首选项—>常用—>Document Swticher

本文链接

Cache缓存示例(WCF)

2012-05-08T10:02:00Z

1、新增缓存

var cache = HttpRuntime.Cache;
cache.Insert(缓存名称, 缓存数据, null, Cache.NoAbsoluteExpiration,
new TimeSpan(0, 绝对过期时间（分钟）, 0), CacheItemPriority.Default, CachedItemRemoveCallBack[回调函数]); 2、缓存回调函数(缓存到期后需要重新添加缓存）/// <summary>
/// 缓存到期后的回调函数
/// </summary>
/// <param name="key">缓存名称</param>
/// <param name="value">缓存的值</param>
/// <param name="reason">缓存到期的原因</param>
private void CachedItemRemoveCallBack(string key, object value,
CacheItemRemovedReason reason)
{}

本文链接

ActionResult类继承结构

2012-05-06T09:26:00Z

2012-05-06T09:26:00Z2012-05-06T09:26:00Z扯http://www.cnblogs.com/gossip/

本文链接

Using Test-Driven Development and the Red-Green-Refactor Workflow

2012-04-25T08:59:00Z

With test-driven development (TDD), you use unit tests to help design your code. This can be an odd
concept if you are used to testing after you have finished coding, but there is a lot of sense in this
approach. The key concept is a development workflo w called red-green-refactor. It works like this:
1.   Determine that you need to add a new feature or method to your application.
2.   Write the test that will validate the behavior of the new feature when it is
written.
3.   Run the test and get a red light.
4.   Write the code that implements the new feature.
5.   Run the test again and correct the code until you get a green light.
6.   Refactor the code if required. For example, reorganize the statements, rename
the variables, and so on.
7.   Run the test to confirm that your changes have not changed the behavior of
your additions.

This workflow is repeated fo r every feature you add.
Let’s walk through an example so you can see how it works. Let’s imagine the behavior we want is
the ability to add a bid to an item, but only if the bid is higher than all previous bids for that item. First,
we will add a stub method to the Item class, as shown in Listing 4-8.
Listing 4-8. Adding a Stub Method to the Item Class
using System;
using System.Collections.Generic;

namespace TheMVCPattern.Models {
    public class Item {
        public int ItemID { get; private set; } // The unique key
        public string Title { get; set; }
        public string Description { get; set; }
        public DateTime AuctionEndDate { get; set; }
        public IList<Bid> Bids { get; private set; }

        public void AddBid(Member memberParam, decimal amountParam) {
            throw new NotImplementedException();
        }
    }
}

It’s obvious that the AddBid method, shown in bold, doesn’t display the required behavior, but we
n’t let that stop us. The key to TDD is to test for the correct behavior before implementing the feature.
are going to test for three different aspects of the behavior we are seeking to implement:

• When there are no bids, any bid value can be added.
• When there are existing bids, a higher value bid can be added.
• When there are existing bids, a lower value bid cannot be added.

To do this, we create three test methods, which are shown in Listing 4-9.
Listing 4-9. Three Test Fixtures
[TestMethod()]
public void CanAddBid() {

    // Arrange - set up the scenario
    Item target = new Item();
    Member memberParam = new Member();
    Decimal amountParam = 150M;

    // Act - perform the test
    target.AddBid(memberParam, amountParam);

    // Assert - check the behavior
    Assert.AreEqual(1, target.Bids.Count());
    Assert.AreEqual(amountParam, target.Bids[0].BidAmount);
}

[TestMethod()]
[ExpectedException(typeof(InvalidOperationException))]
public void CannotAddLowerBid() {

    // Arrange
    Item target = new Item();
    Member memberParam = new Member();
    Decimal amountParam = 150M;

    // Act
    target.AddBid(memberParam, amountParam);
    target.AddBid(memberParam, amountParam - 10);
}

[TestMethod()]
public void CanAddHigherBid() {

    // Arrange
    Item target = new Item();
    Member firstMember = new Member();
    Member secondMember = new Member();
    Decimal amountParam = 150M;

    // Act
    target.AddBid(firstMember, amountParam);
    target.AddBid(secondMember, amountParam + 10);

// Assert
Assert.AreEqual(2, target.Bids.Count());
Assert.AreEqual(amountParam + 10, target.Bids[1].BidAmount);
}

We’ve created a unit test for each of the behaviors we want to see. The test methods follow the
arrange/act/assert pattern to create, test, and va lidate one aspect of the overall behavior. The
CannotAddLowerBid method doesn’t have an assert part in the method body because a successful test is an
exception being thrown, which we assert by applying the ExpectedException attribute on the test method.

As we would expect, all of these tests fail when we run them, as shown in Figure 4-10.

Figure 4-10. Running the unit tests for the first time
We can now implement our first pass at the AddBid method, as shown in Listing 4-10.
Listing 4-10. Implementing the AddBid Method
using System;
using System.Collections.Generic;

namespace TheMVCPattern.Models {
public class Item {

        public int ItemID { get; private set; } // The unique key
        public string Title { get; set; }
        public string Description { get; set; }
        public DateTime AuctionEndDate { get; set; }
        public IList<Bid> Bids { get; set; }

        public Item() {
            Bids = new List<Bid>();
        }

        public void AddBid(Member memberParam, decimal amountParam) {
            Bids.Add(new Bid() {
                BidAmount = amountParam,
                DatePlaced = DateTime.Now,
                Member = memberParam
            });
        }
    }
}

We’ve added an initial implementation of the AddBid method to the Item class. We’ve also added a
simple constructor so we can create instances of Item and ensure that the collection of Bid objects is
properly initialized. Running the unit tests again generates better results, as shown in Figure 4-11.

Two of the three unit tests have passed. The one that has failed is CannotAddLowerBid. We didn’t add
any checks to make sure that a bid is higher than previous bids on the item. We need to modify our
mplementation to put this logic in place, as shown in Listing 4-11.

Listing 4-11. Improving the Implementation of the AddBid Method
using System;
using System.Collections.Generic;
using System.Linq;

namespace TheMVCPattern.Models {
    public class Item {
        public int ItemID { get; private set; } // The unique key
        public string Title { get; set; }
        public string Description { get; set; }
        public DateTime AuctionEndDate { get; set; }
        public IList<Bid> Bids { get; set; }

        public Item() {
            Bids = new List<Bid>();
        }

        public void AddBid(Member memberParam, decimal amountParam) {

            if (Bids.Count() == 0 || amountParam > Bids.Max(e => e.BidAmount)) {
                Bids.Add(new Bid() {
                    BidAmount = amountParam,
                    DatePlaced = DateTime.Now,
                    Member = memberParam
                });
            } else {
                throw new InvalidOperationException("Bid amount too low");
            }
        }
    }
}

You can see that we have expressed the error condition in such a way as to satisfy the unit test we
wrote before we started coding; that is, we throw an InvalidOperationException when a bid is received
that is too low.

Each time we change the implementation of the AddBid method, we run our unit tests again. The
results are shown in Figure 4-12.

Success! We have implemented our new feature such that it passes all of the unit tests. The last step
is to take a moment and be sure that our tests really do test all aspects of the behavior or feature we are
implementing. If so, we are finished. If not, then we add more tests and repeat the cycle, and we keep
going until we are confident that we have a comprehensive set of tests and an implementation that
passes them all.
This cycle is the essence of TDD. There is a lot to recommend it as a development style, not least
because it makes a programmer think about how a change or enhancement should behave before the
coding starts. You always have a clear end point in view and a way to check that you are there. And if you
have unit tests that cover the rest of your application, you can be sure that your additions have not
changed the behavior elsewhere.

本文链接