2012-12-03 95 views
0

我在第一次看单元测试。 因为我在Visual Studio 2008中,我开始使用测试框架构建。我应该为以下哪种方法编写单元测试?

我已经打开按钮,开始看着填充空白,这似乎一切简单。

除了我可以看到两个问题。

1)大量的空白单元测试似乎是多余的,是否有一个经验法则来选择编写单元测试的方法不是而是。 2)是否有编写测试读/写数据库的方法的最佳做法(本例中为SQL Server)

我将给出(1)的示例。

我正在为WCF Web服务编写单元测试。我们首先使用wscf.blue编写我们的Web服务WSDL/XSD。

下面是消耗用户列表并将它们写入数据库的用户表的方法的代码(经过严格简化)。

Entry Point 
    | 
    | 
    V 
void PutOperators(PutOperatorsRequest request) (This method is auto generated code) 
    | 
    | 
    V 
void PutOperatorsImplementation(PutOperatorsRequest input) (Creates a data context and a transaction, top level exception handling) 
    | 
    | 
    V 
void PutEntities<T>(IEnumerable<T> input) (Generic method for putting a set of entities into the database, just a for loop, T is Operator in this case) 
    | 
    | 
    V 
U PutEntity<T, U>(T entity) (Generic Method for converting the input to what the database expects and adding it to the DataContext ready for submission, T is Operator, U is the data layer entity, called User) 
    | 
    | 
    V 
(This method calls 3 methods, first 2 of which are methods belonging to "entity" passed into this method, the 3rd is an abstract method that, when overridden, knows how to consume a BL entity and flatten it to a database row) 
void EnsureIDPresent() (Ensures that incoming entity has a unique ID, or creates one) 
void ValidateForInsert(AllOperators) (Does this ID already exists, etc) 
User ToDataEntity(Operator entity) (simple field mapping excersice, User.Name = Operator.Name, etc) 

所以,据我可以告诉我有3个方法是做显然是可测试的东西:

EnsureIDPresent() - 此方法需要输入和修改它以易于测试方式 ValidateForInsert() - 此方法需要如果不符合条件,则输入并抛出异常 ToDataEntity() - 此方法接受输入,创建数据行实体并填充值。应该很容易测试。

还有:

PutOperatorsImplementation() - 这是在这里,DataContext.SubmitChanges()和TransactionScope.Complete()被调用。我应该编写测试来测试写入数据库的内容吗?然后什么?删除它们的记录?不知道在这里做什么。

我觉得我应该删除试验:

PutOperators() - 自动生成的代码,一行调用PutOperatorsImplementation() PutEntities() - 只是一个for循环调用PutEntity(),这是一个基础上的通用方法类 PutEntity() - 调用三个已经具有单元测试和调用DataContext.InsertOnSubmit的方法。

我有一个类似的路径获取数据,以及:

GetOperatorsResponse GetOperators(GetOperatorsRequest request) - 自动生成

GetOperatorsResponse GetOperatorsImplementation(GetOperatorsRequest input) - 设置的DataContext

List<Operator> GetEntities() - LINQ查询

Operator ToOperator(User) - 展平一个数据实体融入其等价的BL实体中。

我想我应该是测试ToOperator()GetEntities()

我应该有它已知良好的测试数据的专用测试数据库?

这是正确的方法来解决这个问题吗?

回答

0

对于你应该做什么和不应该做什么测试,没有“硬性和快速”的规则。

单元测试在那里测试你的书写作品的任何实现,并使你在重新分解时确信你没有破坏任何东西。你需要考虑你写的测试是否会给你带来价值。

你需要考虑决定什么样的代码覆盖时,主要的事情是

  • 怎么可能是我对写代码/采写可能 变化和需要重构?
  • 代码是否主要写自定义代码或autogenrated - 如果 autogenrated再有就是在编写测​​试你的 小值只是简单地测试使用的是它的工作 正确(你应该能够相信它)自动发生器。

您不应该使用数据库或任何可以在测试环境之外更改的数据来测试数据访问代码。相反,可以考虑编写“Mocks”来模拟数据层对测试的响应。这将确保您的测试一致。考虑看一些模拟框架,如Rhino Mocks或MOQ。

永远记住你正在写测试的原因,而不是写作测试的缘故。如果你不会从你编写的测试中获得任何价值(例如,如果你的代码库不会改变),那么就不要写它们。

+0

好的,有道理,谢谢。我已经开始阅读犀牛手册,我想我看到了一个关于我们如何做事的直接问题。我们有很多对静态属性的调用,它们在范围DataContext中查找当前值。我猜这个模拟方法只适用于传递信息库的情况吗?我们只是把它们拔出来...... – RoboJ1M

+0

如果你正在从物理传感器或硬件读取数据,Mock也会很有用,这样你就不必在一个单元中确保硬件处于特定状态测试。 – Xantham

+0

声音对于手持设备测试非常有用,然后在我们使用GPS,GPRS等的地方 – RoboJ1M

相关问题