代码之家 › 专栏 › 技术社区 › Berlin Brown

Java/J2EE标准实践和设计选择

java-ee testing unit-testing java

Berlin Brown · 技术社区 · 16 年前

在web环境中,如何使用过滤器。什么时候应该使用J2EE过滤器,什么时候不应该?是否可能有许多过滤器,特别是如果您有太多的逻辑在他们。例如,在我们的身份验证过程中有很多逻辑。如果您是此用户,请转到此网站,如果不是,请转到其他网站。调试很困难,因为一个URL路径可能最终呈现不同的目标页面。
JSP文件中替换值的属性资源捆绑文件:Java社区的共识似乎是使用包含标签和标题的捆绑文件进行JSP解析。如果您使用许多不同的语言进行开发,并根据区域设置切换标签值,我可以看到这样做的好处。但是如果你不使用多种语言怎么办?JSP文件或其他模板文件中的每一段静态文本是否真的必须放入属性文件中。我们再次遇到调试问题,其中文本可能由于属性值键拼写错误或属性文件损坏而无法显示。此外,我们还有一个过程,图形设计师将向我们发送html模板,然后我们将它们转换为jsp。然后删除静态文本、添加键、在属性文件中添加键/值,等等,似乎更容易混淆。

例如,labels.properties文件可能包含用户名:label。被某个键替换并呈现给用户的。

所有J2EE开发的单元测试——我们不鼓励单元测试。有些人这样做,但我从未在使用广泛单元测试的商店工作过。一旦place做了,然后当关键时刻来临时,我们停止了单元测试,过了一会儿,单元测试就没用了,永远也不会编译。我所做的大部分开发都与服务器、web应用程序开发、数据库连接有关。我知道单元测试可能会很麻烦,因为您需要一个环境来进行单元测试。我认为单元测试宣言鼓励开发人员不要实际连接到外部源。但似乎测试的主要部分应该是连接到数据库并运行所有代码,而不仅仅是一个特定的单元。这就是我的问题,对于所有类型的开发(如您在面向CRUD的J2EE开发中看到的),我们是否应该在所有情况下编写单元测试?如果我们不编写单元测试,我们还可以使用哪些其他开发人员测试机制?

编辑:这里有一些关于这些主题的好资源。

http://www.ibm.com/developerworks/java/library/j-diag1105.html

4 回复 | 直到 16 年前

Benjamin Cox 16 年前

重定向是根据角色处理不同页面的一种更简单的方法。该过滤器可以简单地用于身份验证,以将用户对象和任何关联角色引入会话。

正如詹姆斯·布莱克(James Black)所说,如果你有一个中央控制器,你就不必把这个逻辑放在过滤器里。为此,您需要将中央控制器映射到所有URL(或所有非静态URL)。然后过滤器将用户和角色传递给中央控制器,中央控制器决定将用户发送到何处。如果用户试图访问他没有权限的URL,此控制器可以决定如何处理该URL。

大多数主要的MVCWeb框架都遵循这种模式,所以只要查看它们就可以更好地理解这一点。
我也同意詹姆斯的观点——你不同意有把所有的东西都搬到那里,但这可以让事情在未来变得更简单。就我个人而言,我认为为了与设计师有效合作,你经常必须权衡这一点。我经常把基础设施和逻辑放进去让它工作,但在与设计师合作时,我的模板中充斥着静态文本。最后,返回并将所有静态文本提取到外部文件中。果然,我发现了一些这样的拼写错误!
测试-这是一个大的。根据我的经验,严格的测试优先方法可以消除开发这些应用程序90%的压力。但是单元测试还不够。

如敏捷社区所示,我使用三种测试:
- 验收/功能测试-客户根据每项要求定义这些测试,我们在它们全部通过之前不会发货(查看FitNesse、Selenium、Mercury)
- 集成测试—确保逻辑正确,并且问题不会跨层出现,也不会在实际数据中出现(查看Cactus、DBUnit、Canoo WebTest)
- 单元测试——既定义了类的用法和期望值,又提供了快速捕获突破性更改的保证(看看JUnit,TestNG)

所以你可以看到,单元测试确实是为了开发者的利益。。。如果我们有五个人在做这个项目,不编写单元测试会导致两件事之一:

当开发人员试图找出如何使用(或某人如何破坏)彼此的类时,必要的通信爆发

可以说,最有用但最不常用的是自动验收测试。这可以确保开发人员理解客户的要求。有时候这要留给QA来做,我认为这很好,但理想的情况是这些都是开发过程的一个组成部分。

“持续集成”只是自动化这一步骤的过程——当任何人签入代码时,一个单独的服务器签出代码并运行所有测试。如果有任何损坏,它会向最后一个开发人员发送垃圾邮件,直到修复为止。

我曾经咨询过一个只有一个测试人员的团队。这家伙整天都在手动完成测试计划。当变化发生时,无论多么微小,他都必须重新开始。我给他们制作了一个电子表格,显示在一个屏幕上有超过1600万条可能的路径,他们很快就为Mercury Test Director支付了1万美元!现在,他制作了电子表格,并自动化了使用它们的测试计划,因此他们进行了非常彻底的回归测试,而不需要不断增加的QA时间要求。

所以,不,没有必要。但是,如果您发现自己担心技术债务,担心本周末的大规模部署,或者担心在尝试快速更改以满足突然紧急的客户需求时是否要打破现状,那么您可能需要更深入地调查测试优先开发。

James Black 16 年前

过滤器有助于移动逻辑,例如用户是否经过身份验证,以正确处理此问题,因为您不希望在每个页面中都使用此逻辑。

因为您没有中央控制器,所以听起来您的过滤器是为这个功能服务的,这很好,但是,正如您所提到的,它确实使调试更加困难。

单元测试确实需要规范,但是,如果规则是没有单元测试就没有任何东西可以交给QA,那么它可能会有所帮助,并且有许多工具可以帮助生成测试,所以您只需要编写测试。在调试之前,编写或更新单元测试,并显示单元测试失败,因此问题重复出现。

这将确保错误不会返回,并且您已经修复了它,并且您已经更新了单元测试。

对于资源束。如果你确信你永远不会支持另一种语言,那么当你重构的时候,你就可以不再需要捆绑包了,但是,我认为如果文本实际上在一个地方,那么拼写/语法更正就更容易了。

Thimmayya 16 年前

资源包对于保持灵活性是必要的,但是如果您绝对知道该站点将在单个语言环境中使用,那么您可能会跳过它。也许您可以将维护捆绑包的部分工作转移给设计师,即让他们可以访问资源捆绑包,这样您就可以获得带有键的HTML。
与将单元测试构建到现有产品中相比,单元测试在项目开始时更容易实现。对于现有软件,您仍然可以为新功能实施单元测试。然而,这需要团队领导一定程度的坚持,团队需要接受单元测试的必要性。单元测试的代码审查很有帮助,决定哪些部分的代码需要完全覆盖可以帮助开发人员。像Coverlipse这样的工具/插件可以指出单元测试的覆盖范围,但是它们倾向于查看每一个可能的代码路径,其中一些可能是微不足道的。
在我以前的一个项目中,单元测试只是强制性的,每次签入后单元测试都会自动启动。然而,这不是测试驱动的开发,因为测试大多是在编写了小块代码之后编写的。TDD可能会导致开发人员编写代码来处理单元测试,因此,开发人员可能会失去他们正在开发的组件的整体形象。

BalusC 16 年前

过滤器用于引导/修改/拦截实际请求/响应/会话。例如:设置请求编码、确定登录用户、包装/替换请求或响应、确定将请求转发给哪个servlet,等等。

JSP文件中替换值的属性资源束文件。

java.util.Properties 应用程序编程接口。

JUnit可以处理它。你也可以考虑“官方”只做用户测试。创建几个用例并对其进行测试。