我想在我的软件开发项目中使用Visual Studio中的Microsoft测试框架实现自动化测试.我已经创建了一些测试,总而言之,它非常易于使用.
有哪些更好的测试业务对象的实践,更具体地说是读取和写入数据库的实践.
是否最好从开发数据库中设置一个单独的测试数据库,从中测试用户界面,然后只测试该数据库?基本上只是填充垃圾数据.
是否更好地接受某种类型的清理后自己的心态,这意味着,如果我正在测试AddUser方法,我是否添加用户,检查我的测试,然后删除用户?
您是否在一种测试方法中测试每种CRUD方法?
最后,如验证字符串的各个业务规则具有正确的大小,开始日期小于结束日期,CustomerId是正确的客户等等.
我意识到这是一个非常广泛的问题......只是寻找一些方向......采取婴儿步骤.
更多信息...
很多很好的答案!我不确定我是否能够启动模拟数据库.我使用CSLA作为我的对象的框架.需要一些严肃的重构才能使用mock对象进行测试.我要调查一下这个.虽然,在某些时候,我确实想测试数据库交互...当使用模拟数据库时,你何时/何时实际测试数据库通信?
另一个问题......最好是保持每种测试方法不依赖于其他测试吗?
理想情况下,您将拥有不直接访问数据库的业务对象,但使用辅助对象或某种ORM(对象关系映射)框架.然后你可以在没有数据库的情况下测试你的BO,可能会模拟一些帮助对象.这可能是最干净的方式,因为您避免了真正数据库的复杂性,并且实际上只测试您的业务逻辑.
如果您无法避免将业务规则和数据库访问组合到一个类中(可能是有问题的设计,但有时难以避免),那么您必须针对数据库进行测试.
几乎唯一合理的选择是使用单独的DB进行自动测试.您的测试方法应删除设置时的所有设置,然后加载所有数据,进行测试并验证结果.
甚至不要考虑尝试初始化DB一次,然后对相同的数据运行所有测试.一次测试会意外地改变数据,其他测试将神秘地失败.我已经做到了并后悔...每个测试都必须独立存在.
为了做到这一切,我强烈推荐某种数据库测试框架.这些可以帮助您清理数据库,加载必要的数据,并将查询结果与预期结果进行比较.我使用DBUnit(用于Java),但还有许多其他语言.
我建议实现您的业务对象,以便他们不知道数据库.在数据访问层上使用可以根据类型正确保存/检索业务对象的方法(即,它具有表和它们对应的对象之间的内部映射).在测试业务对象本身时,您根本不必担心数据库.只需创建对象,可能使用反射来设置私有字段,并对对象进行测试.
在测试需要与数据访问层交互的代码时,使用模拟来创建模拟数据层并对其设置期望以返回所需对象或正确响应保存.您可能需要将数据层开发为接口(或者如果使用不直接支持模拟的严格框架,则将其与可模拟类包装在一起).大多数模拟框架都要求方法是虚拟的,以允许创建模拟实现.使用接口强制实现类中的方法是虚拟的,因此模拟更容易.