如何使用 UnitTest 或 XP 進行 EJB 專案, 是否有簡單的方法

如果你的项目用了EJB，测试环节就会面临很大的困难。与POJO相比，EJB必须部署到容器中才能测试，这大大降低了测试的效率，而更重要的是，EJB很难Mock，对于业务逻辑比较复杂的系统，离开MockObject，就必须额外维护单元测试的数据库环境，这是非常困难的一项任务－－EJB的复杂性蔓延的让人不敢想象！一旦测试这一重要环节受阻，产生的后果可想而知！

EJB与重构、测试等敏捷开发元素将程序员引向两个截然相反的方向！EJB让程序员背离OO设计思想，继续走过程化设计的老路；而重构以一种很自然的方式改善设计，让你在不知不觉中掌握设计模式；测试也会反过来影响代码的质量，在提高可测试性的同时，代码也在趋于优化（例如从MockObject引入IoC）。可以说重构、测试不仅本身是Best Practise，同时也是帮助程序员提高素质的途径。

呵呵，这就是我准备过些天披露的 Rod Johnson 对于 EJB 的几个主要观点之一。我最近特别忙，懒得跟某些人费口水。原本准备在我的翻译工作全部做完后再来这里兴风作浪，不料被你抢先了。

这里先公布 EJB 的两条罪状：
1、针对 EJB 的单元测试难以进行。
2、在使用 EJB 的团队中难以应用敏捷开发过程。

大家来点评一下，不过最好都专业一些，不要再扯什么商业、标准或者“今天的天气”之类的无聊话题了。

http://mockrunner.sourceforge.net/examplesejb.html

就算你有再先进的工具、再好的测试框架，在我的P4 1.7G+512M电脑上，重新编译、构建、部署EJB至少需要一分钟。如果每次执行测试只需要10秒，我可以频繁执行它们；如果需要一分钟，TDD的热情就会遭到严重的打击。

to jini：
EJB 完全能够做单元测试这个是肯定的，我 100% 相信。但是能够做单元测试还要考虑一个成本。EJB 组件时时要注意容器的存在，离开了容器就根本无法运行，这个确实大幅度增加了组件测试的难度。而 Spring 等轻量级的容器具有小的多的侵入性，使得组件测试要容易得多。o6z 甚至提出一种设想，将来出现一种无容器的组件，或者说这个组件可以部署在任何一种符合某种标准的容器中（EJB 的承诺，但是很可惜实现的并不好）。这种组件的测试将极其方便，基本上就和测试普通的 Java Class 没有什么区别。Rod Johnson 认为在 .NET 中并未出现明确的容器概念（模糊了“容器”和“管理”的区别）是一种更好的设计方法。

敏捷开发过程极端依赖单元测试，而单元测试执行的频率和成本确实会严重影响敏捷开发过程的采用。这在很大程度上是一个心理学的问题，再说下去就离题了。

所以我们这里讨论的其实并不是 EJB 能不能做单元测试的问题。而是讨论究竟哪种方案更容易做单元测试、成本更低的问题。

我沒有否認 EJB 需要更大的部署時間成本.
你們仔細檢查你們自己上面的文章, 是說 EJB 很難進行單元測試, 尤其是 Mock
是你們把問題搞在一個小範圍..
我只是想提醒你們並非如此

如果現在問題要變成 EJB 是否可以容易地做 UnitTest , 需要我告訴你方法嗎 ?
你有自己嘗試過嗎 ?
是不是在你的腦海中, EJB 完全一無可取. 自然而然就不會想要去嘗試 ?

最後, 我並非瞧不起 Spring, 更沒有一定要用 EJB, 我只是希望你們能夠客觀地探討問題, 而非拿著 Without EJB 這本書, 抱著 他的言論, 就開始數落 EJB 的不是. 每項技術都有他的優缺點.. 你完全否認 EJB 的思路真的令我覺得遺憾.

哈哈 .. 這篇文章應該修改成為
"如何使用 UnitTest 或 XP 進行 EJB 專案, 是否有簡單的方法"
這樣子的題目 才可能好好地討論

今天的題目定成
"EJB带来了什么？－－近期阅读心得"
根本就是準備要吵的, 何必在乎到底是吵什麼呢

如果這個題目就是在討論 " with EJB vs without EJB "
我還是得說, dlee 你的論點太主觀, 根本不客觀
在不客觀的環境之下很難有讓人信服的答案
希望你能夠知道我在說什麼

jini
我想你说
你说并非如此,是说EJB可以很容易的进行单元测试,还是说EJB可以很简单的mock?
而后来你干脆直接的说"需要我们告诉你方法吗?",而刚好我们这些人都真的需要你能告诉我们怎么可以简单的、便宜的进行EJB的测试。
尝试一个东西有没有一个前提呢？是不是所有的东西都要去尝试呢？而现在这个问题你可以不回答，只告诉我们你究竟怎么尝试了对EJB做了单元测试。别人说EJB不好，你反驳他们的最有力证据就是找出现实的例子来，而这个EJB可以简单便宜的测试就是最有力的证据。
等待你的回应。

to jini：
我已经把题目改好了。希望 muziq 不会怪我。
我也觉得我们还是把讨论局限于这个小的范围比较好。我们现在没有采用 EJB，我说的很多观点确实是来自于 without EJB 这本书（当然我感觉这本书的观点与我以前的实践经验还是满接近的）。不过我比较喜欢多听取些正反两方面的意见。比如以前 IBM 总是说 Swing 没有办法做到与 native GUI 相同的界面，一定要使用 SWT。后来有个 Swing 高手不信邪，完全用 Swing 实现了与 Eclipse 完全相同的界面。
昨天和朋友讨论 Rod Johnson 和 Ed Roman 到底哪个高，我认为 Rod 要高一些，而他认为 Ed 更高。 我说我认为 Rod 高的原因是 Rod 是一个自出机杼的人，而 Ed 不是。Rod 使用 Spring+AOP 解决了很多大多数人认为只有 EJB 才能解决的问题，所以我感觉 Rod 还是比 Ed 高那么一点点。其实现在业界对于轻量级容器的需求已经越来越大了，如果没有 Open Source，J2EE 的前景真的是很难预测。当然这些都是题外话了，Rod 和 Ed 也根本不会对谁高谁低的无聊评论感兴趣的。

从我个人来讲我现在有点越来越崇拜 Rod 这家伙了，without EJB 是我现在最想读完的一本书。当然盲目的个人崇拜也是不好的，我非常期待 jini 能够给我们带来一些我们未知的观点。

Good luck!

个人认为，删除帖子不是什么问题，但是在一个话题正在进行过程中，删除其中的某一些帖子，是不妥的。

最多到话题了解的时候，再删除里面的口水好了。即时删除，难免......