一直搞不懂unit test要从何做起、好处何在 最近处理比较敏感的资料 开始试着写unit test 终於慢慢知道在MVC架构中 替Model写测试的好处何在 想跟大家分享一下我的心得 好读版 http://blog.turn.tw/?p=110 ------------------------------- 在web的MVC架构中，我们开发时本来就不断在test。 你一直对网页按重新整理就是在test 你在刚写好的页面上输入一些测资然後按确定，也是在test你的controller或model 也就是testing的工作你其实一直都在做。 而MVC架构中的Model特别难处理，因为Model的行为很难测。 在资料到达Model之前，会先经过View、Controller， 所以你会来回狂测，想确定bug到底在 哪。 是jQuery在抓网页元素的value时抓错？是JavaScript相关的code有bug？是html的某个 form name打错？是Controller拿到form POST的值时做了变数型态转换？ 是Controller里面变数名称打错？是丢变数给Model时顺序丢错？ 还是Model里面有bug？ 反覆跑完以上流程抓出bug就算了，偏偏并非每个功能都是直接在网页上key完资料就丢给 Model。 结果光是想丢测资给Model就很麻烦。尤其你修好一个method常会想确认其他method有没有 因此坏掉。 行为单纯的Model就算了，以上过程还不会花掉太多时间。 复杂一点的 Model真的是debug到会在电脑前大骂脏话。 针对Model写单元测试等於在开发Controller跟View前，先把Model弄得很强壮。 为了搞清楚自己的Model有多健康，你会写好几个test、丢好几笔测资。 加上为了要让model能被test，你会来回去修改、把model写的更模组化、更testable 、 让使用Model的人用得更愉快。 然後使用Model的人就是你自己。 所以unit test写完、测完，你再写controller跟view的时候就快乐到爆。 因为你知道写Model的那家伙很猛、把它写得很强悍（乱丢资料也不会怎样， 那个Model会丢Exception、会丢error、会吐讯息， 反正Model会强力守住最後一道关卡 资料库绝对不会烂掉。） 所以你Controller跟View就可以轻松写，顶多就是使用者key错资 料会看到exception或是一些怪怪的错误讯息，绝对不会有资料库存到坏掉的资料或是资料 一致性的问题出现。 开发上出现bug时，你也可以确定是controller或是view的资料处理出错，千错万错绝不是 Model的错。（那真的是Model有bug怎麽办？回去再写几个test抓bug，然後修好就行罗） 然後我认为，单元测试也不需要把所有可能的测资、全部使用情境都测过。 每个method随便写几个最笨的testing就很够了 ，通常有bug就是return value完全跟预期不一样。 写几个笨testing就够抓出一堆麻烦了。 像是： 资料库某table在新增完有没有多一笔 各栏位金额加总有没有等於总金额栏位 那个要抓10笔资料的method最後抓到的是不是10笔 乱丢变数给某method有没有吐Exception 只测试这些够混吧？但是最常搞出来的bug就是这麽单纯而已。 当这些testing都跑过了，你的Model已经非常头好壮壮了，超健康。 眼看自己动手去挑战自 己的Model，最後还全部过关，绝对会信心UP、UP。处理复杂的Model时， 将省下很多时间。 （就算不写单元测试，你也是用浏览器东测西测、花时间抓bug不是吗？） 好，做个整理。 时机 某Model光用想就觉得头痛，开发起来你觉得很没安全感 好处 让你跳出开发者的角度，从使用者的角度去看这些method好不好用、 直不直觉，因此能写 出更出色（reusability, maintainability, scalability）的Model 每次改完某method，都能立刻检查其他的method有没有被搞坏 更好抓bug（写testing时会在Model狂抓bug。之後写controller/view时， 你会知道bug都在controller/view里面，不用跳来跳去检查一堆code） --

※ 发信站: 批踢踢实业坊(ptt.cc) ◆ From: 118.167.4.247