我们是否要为了测试而写代码？

[flyforlove]

实现同样的功能，每个人写的程序不同。
以前我写程序，喜欢最简化原则，就是说，用到了数据，才去取，而不是先准备好。

比如说有个类是这样的
class MyCls
{
public string GetValue()
{
string str = process_1();
........................
return ret;
}
private string process_1()
{
string str = process_2();
.......................
return ret;
}
private string process_2()
{
string str = process_3();
.......................
return ret;
}
private string process_3()
{
.......................
return ret;
}
}

但是这样的设计带来的直接问题是不好测试，因为测试process_1()的时候就牵动着process_2，process_3........也许更多的方法。

于是把上面的类改为
class MyCls
{
public string GetValue()
{
string str3 = process_3();
string str2 = process_2(str3);
string str1 = process_1(str2);
........................
return ret;
}
private string process_1(string str2)
{
string str = str2;
.......................
return ret;
}
private string process_2(string str3)
{
string str = str3;
.......................
return ret;
}
private string process_3()
{
.......................
return ret;
}
}

这就免不了要传递参数。
而对于单元测试，传递参数的方法居然是最好测试的。

有的时候对于一个多方法会用到的变量，就喜欢把它做成field，同样也会带来测试问题。

突然发现自己不会写程序了。

[flyforlove]

怎么看都觉得unit test是面向过程设计的东西，

我希望有人能发明一个以类为单位的 class test

[flyforlove]

居然没有人关心？？？

大家都不做单元测试么？

[shrinerain]

如果按照你第一种方法,耦合度太高,不利于重构.

[lr21shiji]

不做单元测试

[pop_andy_feng]

还是写点代码吧
要不日后可能写的更多
个人建议。。。

[flyforlove]

shrinerain(圣影雨) ( ) 信誉：100 Blog 2007-02-07 15:22:02 得分: 0


如果按照你第一种方法,耦合度太高,不利于重构.


--------------------------------------------------------

但是第二种方法也带来了很多问题，那就是在GetValue()方法中，它访问到了很多不该它访问的方法,因为process_2,process_3的结果对于它来说没有任何意义，它要得只是process_1的结果。