2010-08-23 283 views
6

我是单元测试新手。假设我正在构建一个Web应用程序。我如何知道要测试什么?你看到的所有例子都是某种基本的求和函数,它实际上没有真正的价值,或者至少我从来没有写过一个函数来添加输入,然后返回!你用单元测试测试什么?

所以,我的问题......在Web应用程序上,需要测试什么类型的东西?

我知道这是一个广泛的问题,但任何事情都会有所帮助。我会对链接或任何能够提供真实生活实例的东西感兴趣,而不是那些没有任何真实生活用法的概念实例。

回答

2

看看你的代码,尤其是你有复杂的逻辑与循环,条件等位,并问自己:我怎么知道这是否工作?

如果您需要更改复杂逻辑以考虑其他角落案例,那么您如何知道您所引入的更改不会破坏现有案例?这正是单元测试旨在解决的问题。

因此,要回答您关于它如何应用于Web应用程序的问题:假设您有一些代码根据浏览器对页面进行不同的布局。你的一个客户拒绝从IE6升级,并坚持认为你支持。因此,您通过模拟IE6中的连接字符串并检查布局是否符合您的期望,从而单元测试布局代码。

一位顾客告诉你他们已经发现了一个安全漏洞,使用特定的cookie会给你管理员访问权限。你怎么知道你已经修复了错误,并且它不再发生?为它创建一个单元测试,并且每天运行单元测试,以便在失败时得到预警。

您发现一个错误,其名称中带有重音的用户在数据库中遭到损坏。从数据库层抽象出网络表单输入并添加单元测试,以确保(例如)UTF8编码数据正确存储在数据库中并可被检索。

你明白了。任何地方,部分流程都有明确的输入和输出,非常适合单元测试。任何不是理想的重构,直到它被明确定义。看看诸如WebUnit,HTMLUnit,XMLUnit,CSSUnit等项目。

2

测试的第一部分是编写可测试的应用程序。从UI中分离出尽可能多的功能。重构成更小的方法。了解依赖注入,并尝试使用它来创建方法,这些方法可以采用简单的可抛弃输入来生成已知(并为此可测试)的结果。看看嘲笑的工具。

基础架构和数据层代码最容易测试。

看看行为驱动的测试以及测试驱动的设计。对于我的钱来说,行为测试比单纯的单元测试要好;您可以遵循用例,以便测试与预期的使用模式相匹配。

0

对于Web应用程序,您需要做的测试类型稍有不同。单元测试是测试程序的特定组件的测试。对于Web应用程序,您需要测试表单是否接受正确的输入,所有链接指向正确的位置,它可以处理意外的输入等。如果我是你,我会看看Selenium,我已经在测试多个站点时广泛使用它:Selenium HQ

0

我没有测试网络应用程序的经验,但通常会说:您可以单元测试程序中最小的“块”。这意味着您可以在单独的基础上测试每个功能。大规模的任何事情都会成为一种综合测试。

当然,会有这么简单的方法,它不值得您花时间为他们编写测试,但总体目标是测试尽可能多的代码。

1

单元测试意味着测试任何工作单元,最小的工作单元是方法和函数。单元测试的艺术是定义一个函数的测试,这个函数不能通过检查来检查,单元测试的目标是测试方法的每个可能的功能需求。

考虑,比如你有一个登录功能,那么就可能是你可以为失败编写以下测试: 1.该功能对空的用户名和密码 2.未能在正确的用户名是否该函数失败,但错误的密码 3.请问功能上正确的密码,但错误的用户名

的你也写测试失败,该功能会通过: 1.关于是否正确的用户名和密码的功能通

这只是一个基本的例子,但这是单元测试的尝试实现,测试可能在开发过程中被忽略的事物。

然后还有一个纯粹的方法,开发人员首先应该编写测试,然后通过这些测试(又名测试驱动开发)的代码。

资源: http://devzone.zend.com/article/2772 http://www.ibm.com/developerworks/library/j-mocktest.html

+0

+1为真正的好链接。我喜欢devzone.zend.com文章最好。 – Icode4food 2010-08-23 16:30:27

1

如果你是新来的TDD,我可以提出一个快速访问到BDD的世界?我的经验是,该语言确实可以帮助人们更迅速地获取TDD。特别是,我点你在本文中,其中单北暗示“要考什么”:透明度

http://blog.dannorth.net/introducing-bdd/

注:我可能是大量参与了BDD运动。

关于在Web应用程序中进行单元测试的类,我会考虑从控制器,域对象(如果它们具有复杂行为)以及任何名为“service”,“manager”,“helper”或“util” 。也请尝试重命名这样的类,以便它们不那么通用并且实际地说出它们的作用。称为“计算器”或“转换器”的类也是很好的候选者,您可能会在同一个包/文件夹中找到更多类。

有一对夫妇的好书,可以帮助你太:

  • Martin Fowler的 “重构”
  • 迈克尔羽毛

祝你好运 “修改代码的工作” !

+0

为伟大的链接+1! – Icode4food 2010-08-23 16:29:52

0

经验法则是,如果它不值得测试,则不值得编写。

但是,有些事情是非常难以测试的,所以您需要对测试内容做一些成本效益分析。如果您最初的目标是70%的代码覆盖率,那么您将走在正确的轨道上。

1

如果您开始说“如何测试我的网络应用程序?”那就是一次咬掉很多,单元测试很难让人看到任何好处。我从单独的小块开始进行单元测试,然后编写测试优先库,然后才构建可测试的整个应用程序。

通常,一个web应用程序具有一个域模型,它具有数据访问对象,用于对数据库执行查询并返回域对象,具有调用数据访问对象的服务,并且具有接受http请求并调用服务。

控制器的测试将检查他们是否使用正确的参数调用正确的服务方法。服务对象可以在测试设置期间被模拟注入。

服务测试将检查他们调用正确的数据访问对象并执行他们需要执行的任何逻辑。数据访问对象可以在测试设置期间被模拟注入。

数据访问对象的测试将通过检查数据库之前和之后的内容来检查它们是否执行正确的数据库操作(查询或更新或其他)。对于dao测试,您需要一个数据库和一个像DBUnit这样的工具来在测试之前预先填充它。此外,您的域对象的getter和setter将通过此测试得到行使,因此您不需要为它们单独测试。

域模型的测试将检查您编码的域逻辑是否有效(有时您可能没有)。如果您设计的域模型不与数据库耦合,那么您放入域模型的逻辑就越好,因为它很容易测试。这些测试你不应该需要任何模拟。

相关问题