在了解 TDD 究竟是什么之前，我就一直在编写测试驱动的代码。在没有实现的情况下调用函数和类有助于我以更快、更有效的方式理解和构建我的应用程序。所以我非常习惯编写代码->编译它->看到它失败->通过构建它的实现来修复它。
这个过程对 Web 来说有点困难。特别是 JSP。当我编译我的 Java 类时，一切都很好，我可以看到编译错误。但是，在 JSP 中看到错误需要我打开浏览器并调用该特定 JSP。
有没有办法避免这个过程并在不实际加载浏览器的情况下向我显示 JSP 编译错误？
【问题讨论】：
当然。您可以预编译 JSP。甚至有蚂蚁任务可以做到这一点。请参考链接：http://ant.apache.org/manual/Tasks/jspc.html
但我认为这只是第一步。这将允许您查看编译错误。我认为您想要更多，即单元测试。我相信像 Jakarta Cactus（或其他）这样的工具可能会对您有所帮助。
顺便说一句，最近我发现了以下resource，它列举了大量的java测试工具。
【讨论】：
我通常不直接测试 JSP。在您的 JSP 中保留尽可能少的逻辑通常是一个好主意，如果您的 JSP 只包含几个 <c:out> 标记，那么实际上并没有太多需要测试的东西。但是，如果您在其中确实有大量逻辑，那么我要做的就是将该逻辑提取到自定义标签中，您可以很容易地进行测试。
【讨论】：
编译是很容易的部分，我认为 AlexR 的回答处理得很好。
测试和测试 JSP 很困难，因为测试它确实需要部署到 Web 容器或模拟（模拟）它，并通过浏览器或模仿浏览器的东西运行。
Cactus 可以帮助进行容器内测试。 Selenium 也可以。
或者你可以模拟环境。如果你使用Spring，它有一些很好的支持。
但是解决测试和测试驱动 JSP 的困难的最好方法是完全停止使用 JSP，或者至少通过避免使用 scriptlet 来最小化 JSP 代码中的逻辑。
由于 JSP 只是一个伪装的 servlet，所以在没有 JSP 的情况下编写 Web 应用程序总是可能的，并且可以选择使用像 Wicket 和 Tapestry 这样的框架或像 Velocity 这样的模板引擎来进行 Java Web 应用程序开发没有 JSP 很容易。
【讨论】：