你的代码可测试吗？

你的代码可测试吗？

TDD似乎给人一种代码能够被测试的感觉，但实际上它是一种
设计手段（或方法）。

代码的可测试性与可阅读性是同等重要的。

很多代码写出来不可读，更别提可测了。

最近测试一个产品，大量使用了JavaScript。结果自动测试
工具无法识别；

当然可以认为自动测试工具不好；

但是，是不是设计上也有问题呢？

不是所有的代码都可以被自动测试，也不是所有的设计都应该使代码能够被自动测试。既然设计就是权衡与妥协，有时为了达到某个目的而导致代码的可测试性不好，未必就是设计的问题。具体问题还是应该具体分析吧。

软件的可测性会越来越重要。

设计的时候就要考虑可测、易测。

测试与设计是基本同步进行的；
需求要可测；
设计要可测；
代码要可测；

而我们目前说的基本是代码的可测性。

软件从设计开始就需要是可测试的，一直到编码，甚至于你的架构。例如设计时就需要考虑如何加mock object，否则你拿什么保证你的质量。至于js, 它们也是对象，我想应该是有工具可以使用的吧

“可自动测试”与“可测试”不是完全相同的概念。

的确是有些却别的；

但是目前很多人写代码，工作还干不过来，哪有空管他是否可测试；
我想可测试可以从一下角度考虑：

1。应用程序有利于使用程序编写测试用例（例如单元测试）

很多时候，代码写出来了，接口定义不好，单元测试的代码写起来很费劲；

2。应用程序有利于使用工具进行测试

尽量使用可被测试工具识别的方式编写应用；

3。应用程序尽量符合相关平台的使用习惯

对于Windows程序，应该使界面等风格与Windows一致，一般不要使用
公共组件；

能覆盖80％的白盒用例很不错了，更别说ui这些根本无法进行单元测试

能覆盖多少各个公司有个个公司的标准；至于实际上覆盖了多少，似乎也没有一个准确的衡量办法；

至于UI吗，单元测试可能是不太方便，但是毕竟还是可以测的；
比如对于B/S架构，如果你没有大量使用JavaScript，那么HttpUnit可以满足大部分的单元测试要求；

我不知道ui的单元测试意味着什么，我曾经尝试着在test case里对一个java application的各部分ui发送各种事件，然后坐在椅子上看这个ui以每秒n次的
频率在点击.关闭.打开，可是后来我发现，如果打开出去逛圈回来，不是看junit报告（就是那个红绿条）而是去看别的地方（程序日志等）都不是单元测试，那些测试应该明确的从单元测试中独立出来，而冠以性能测试，功能测试...并且在测试类名上明确标示，TestA. PerformanceTestA......

请各位指点

不知道这样在一个公司的初期投入成本是多少