明天打算给那些组件所有public的方法写上测试用例--虽然花时间给别人的代码写测试是极为无聊的行为，但是现在我也认了，不能再这样提心吊胆得写代码和手工测试了，宁可花上一个上午甚至更多的时间来写用例搭建环境。Rod Johnson说得对极了,牛仔式真是编程害死：满天飞的工厂模式、单例、静态变量，什么注释都没有的监听接口----最重要的是，没有测试用例--乃还算程序员吗？知道老子花了多少时间来拜读修改重构step in,step over您的"大作"？holy shit.

Del.icio.us : java zqc test 单元测试

　　springframework.org论坛里有条评论，翻译过来大概就是说，srcp程序说到底"就是用几个jar和配置文件把你的swing应用组织起来的有着复杂的设计结构的xx"（好吧我不理解乱翻译），说起swing，为了兼顾各个方面的因素(主要是concurrency)，swing的开发者们不得不让swing的使用者们在一个迂回曲折的环境中编写他们的应用。这就好像在一座庞大的金字塔内部观察它的建筑结构一样，你会发出阵阵惊叹；也会绉起眉头迷惑不解--开始的时候后者是远远多过前者的。回过来看看现在如火如荼的web开发，想想，web开发是不是在走10几20年前的老路，什么才是程序的真谛呢？

接下来准备学习一点数据挖掘方面的知识，具体点是语义分析。因为公司在数据采集这方面还相当原始的spider+手工收割，和st谈到这个时也提到个可选的方案，天知道那个看上去不良少年一样的家伙脑袋里到底装了多少东西。好了，这周打算拖拖拉拉地把自动更新updater写完，顺便看看有没机会弄成一个通用的updater。第一期的业务逻辑不复杂，所以也暂时没我什么事，正好可以一只脚站在门外细心瞅瞅，其他等评估结果出来了再说。刚才收信时候看到有封14号的offer letter，密密麻麻的英文搞得foxmail都把它丢到垃圾箱里去了。

原题要求用java，用python只是为了方便。用回溯法快，但是还是坚持用遍历森林来写，这也是面试时没想完的思路，呵呵，我就是自找麻烦的硬石头性格。

最先想到用无向连通图进行深度优先搜索，但是没有考虑到结束条件。对于N个待排列的数字，每个节点都有N-1个出口和入口，而用树状结构每个节点只有一个父节点，存在递归返回的条件。但是这个方法的实用性只限制在当排列数很少（N < 8）时。当N>8时算法消耗的时间明显增加(一共8*7*6*5*4*3*2*1=40320种组合)，当N>1000时(当然，这种情况是不敢想像的)就会达到python的递归极限。所以真正如果要干点什么的话(当然，高中生都知道全排列拿52张扑克牌出来排一下结果集就是个天文数字)，这显然不是个好算法。

#coding=utf-8

# 数字全排列
# Chris Zheng 2007-06-05

import sys, os


#待排列的数字
NUMS = [1,2,3,4,5,6]

#结果集合
results = []

EXCLUDES = (
lambda a,b,nums:abs(nums.index(a) - nums.index(b)) == 1, #a,b是否相邻
lambda a,b,idx_a,idx_b,nums:nums.index(a) == idx_a and nums.index(b) \
== idx_b #a,b是否同时符合特定位置
)

# 3和4不能相邻 当2在第1时6不能在第7
EXT_PARAMS = (
(3,4,NUMS),(2,6,1,7,NUMS)
)

#检查排除条件
def __check_conditions(nums):
matchs = False
for f in EXCLUDES:
for params in EXT_PARAMS:
try:
params[-1] = nums
matchs = f(*params)
if matchs: return matchs
except Exception:continue
return matchs

#树节点
class node(object):
def __init__(self, n):
self.value = n
self.parent = None
self.children = []
def __eq__(self,other):
return self.value == other.value
def __str__(self):return str(self.value)

#主方法
def get_all(nums):
trees = []
for n in nums:
trees.append(create_tree(node(n)))
for t in trees:
walk_tree(t)
global results
#过滤条件
return (r for r in results if not __check_conditions(r))

#生成结果树
def create_tree(root):
parent_elements = __parents(root)
if len(parent_elements) == len(NUMS)+1:return root
nums = (nums for nums in NUMS if node(nums) not in parent_elements)
for k in nums:
c = node(k)
c.parent = root
root.children.append(create_tree(c))
return root

def __parents(node):
parent_elements = [node]
while node.parent:
parent_elements.append(node.parent)
node = node.parent
return parent_elements

#遍历结果树
def walk_tree(root):
if root.children:
for n in root.children:
walk_tree(n)
else:
k = [root.value]
p = root.parent
while p:
k.append(p.value)
p = p.parent
k.reverse()
results.append(k)

#测试输出
if __name__=='__main__':
rs = get_all(NUMS)
f = open('results.txt','w')
for k in rs:
f.write(str(k)+'\n')
f.close()

.

Issue 1: Poor integration tests, as everything is being tested in isolation

I’ve had good experience with mock-based testing. However, it’s obvious that mocks will only test classes in isolation. I use both unit tests and integration tests (sometimes called system or acceptance tests) together. The need for integration tests is not an issue for mock-based techniques and is not a good reason to use less mocks. It’s just a different aspect of testing. A more common issue in my experience is that people in the agile community who are new to testing often don’t understand these different aspects of testing and seem to believe that mock-based unit testing and integration testing are mutually exclusive options. The lack of common terminology in the community only worsens the problem. For some people, a “unit” is a class or small group of tightly coupled classes. For others, it’s a large portion of the software product. Most agile developers seem to call every test they write a unit test. It’s become so confusing for some teams that I’ve seen terminology like “integration unit tests” being used to describe testing strategies.

But, back to the topic. Poor integration testing is simply the result of lack of integration tests. Mocks do not cause a lack of integration tests. A team makes that choice, probably based on a weak understanding of the tradeoffs between isolation (unit) and integration (system) testing.

Issue 2: Mocks add complexity to the software design.

“I’ve seen numerous occasions where the introduction of mocks has added a large amount of complexity to an otherwise simple design. This complexity leads to higher implementation costs, a higher cognitive load on the developers working on the system, and higher maintenance costs (as there’s more code to maintain). “

The author appears to focused on the increased use of interfaces when using mock-based testing and expresses the opinion that interfaces should only be used where we’d want to be able to replace one implementation with another. First, there are other reasons to use interfaces. In general, interfaces are useful for managing dependencies between software components or subsystems. This can be beneficial even if the implementations do not change (see The Dependency Inversion Principle).

A modular software design will generally make it easier to use mock-based testing without altering the design specifically for the mocks. However, there are times when the software must be modified to support testing. Fortunately, the changes needed to support testing often, if done well, support the modularity goal.

In my experience, extra interfaces don’t add a significant maintenance overhead. Most effort is spent implementing the interface. The time writing the interface itself (or extracting it using an IDE’s refactoring tools) is negligible.

My Conclusions

In almost every case, I see the “simplicity” gained by not using mocks overshadowed by complex test setups to initialize large groups of dependent objects. The dark side of integration testing is that it’s often very slow for large numbers of tests. Some teams are using continuous integration tools like Cruise Control to run their “unit tests” (usually they are actually integration tests). This delays the feedback about broken builds but is often necessary because the tests run so slow. I realize there other reasons for using CC, but this is a common one from what I’ve seen and heard.

I’ve worked on teams where we had thousands of tests that ran in less than 15-20 seconds total on a developer workstation. This was a direct result of heavy use of mock-based testing. We also had a slower suite of integration tests that required 4-5 minutes to run. We didn’t need a continuous integration server because we were able to integrate and run our unit tests before every commit to the source control system. The team integrated 10-20 times/day and broken builds were practically nonexistent over the several years I worked with them. In the very rare cases when the build did break, it was typically fixed in a matter of minutes.

The other benefit of the isolation testing enabled by mocks is the ability to pinpoint problems much more quickly. It’s a form of the divide and conquer problem solving strategy, only the divide part is already done. The conquering is relatively easy compared to tracking down the cause of test failures when many classes are being exercised in a test.

My experience was that our mock based unit tests caught about 98% of the code problems before the code was ever committed to source control. The integration tests caught about another 1% beyond that (almost always because of a flaw in the mock-based testing) and manual testing caught the other 1%.

2006-05-22 增加 5.1 初始化 velocity
2006-05-21 增加 4.1 - 4.2 HttpSession操作


更新note:
1.HttpServletRequest的getParameterNames() 方法返回的Enumeration相对于页面参数的物理顺序刚好是相反的,所以实现@ToList标签时候需要先用一个Stack来对所有参数进行反转.不知tomcat在这个api方法上是怎么实现的,为什么就倒过来。c语言函数可以根据不同的call类型来指定不同的压栈的顺序，莫非这个惯例也被用到servlet里面来了，挺有意思的东西，看来需要留意一下。

问题和解决方式:

1.关于@ToSession标签.如果是登陆的话,那么就有个判断条件决定某个login token是否应该被加到session中,这时候可以在@ToSession标记的getter方法中加入逻辑判断,来决定返回一个token实体或者null(这样做有点古怪..).

2.路径的问题.比如一个http://host/logic/bbs/admin/ListUsers.wff 摸版的相关资源目录(比如,图片,css,js等)就必须存在webproject/bbs/admin响应的目录下,有点像struts的多模块.

开始:

Ruby on Rails有个设计思想是用编码规定代替繁琐的配置文件。jvm平台已经有一些类似ror的实现，比如
grails(http://docs.codehaus.org/display/GRAILS/2006/03/29/Groovy+on+Rails+(Grails)+0.1+Released)

虽然由于java自身的局限，它很难做出像ruby或者groovy那样动态语言那样随心所欲的动作，但是利用它的运行时反射、动态代理等特性来尽可能实现“用编码规定代替繁琐的配置文件”这一思想。
下面转入正题。

ServletAPI对HTTP协议进行了封装,通过配置Web.xml来把不同的请求转发给不同的servlet来处理。Web框架则用一个ActionServlet，根据自己的对Action的定义来转发请求。
抛开那些繁琐的配置文件，设想一下这样一种方法:

1.Web动作的处理和响应

假设这样一个POST请求:

  <form action="logic/group/NewTopic.wff" method="post">

Web动作实现Bean:
   org.qqsns.web.logic.group.NewTopic  
注意后面的logic/group/NewTopic和logic.group.NewTopic, 动作类和Web动作是通过请求路径和包名相互关联。
这样，对Web动作的响应就依赖于编译期的代码的组织结构而不是执行期的配置文件。这样的好处是避免了维护繁琐的配置文件,特别是在没有IDE支持的情况下。

org.qqsns.web.logic.group.NewTopic类是一个实现net.wff.servlet.WebAction接口的POJO，下面是NewTopic中execute的方法片段:  
 
 //Only method must be implemented for interface net.wff.servlet.WebAction
 public String execute(WebParam param, VelocityView view)
 throws ServletException, IOException{
  ...
  //return "redirect /success.html";  //请求重定向
  return "/success.jsp";              //请求转发
}
execute方法的返回值手动指定了一个转发或重定向的路径。

2.输入验证

普通的Web框架都带数据输入验证功能,一般复杂程度和功能强大与否成正比。
这里简单地要求从setter方法里抛出一个包含验证信息的异常，以此来实现输入异常处理。
      
普通setter方法
public void setName(String name){ 
  this.name = name;
}

添加输入验证后的setter方法

public void setName(String name) throws InputException{   
 if(name.length()<3)
    throw new InputException("Topic name must has a length greater than 3"); 
  this.name = name;
}

在WaterFallServlet如何中处理验证信息:

    WebAction wa =
    (WebAction)Class.forName(classPath).newInstance();
          //procces forwarding
          try {
    ActionHelper.setProperties(request,wa);
   } catch (InputException e) {
    //return to input view
    //header:referer
    String rtn = request.getHeader("referer");
    //clear old errors
    if(rtn.indexOf("?")!=1){
     rtn = rtn.substring(0,rtn.indexOf("?"));
    }
    rtn=rtn+"?error="+URLEncoder.encode(e.getMessage(),"UTF-8");
    response.sendRedirect(rtn);
    return;
   }

这样验证信息通过请求参数传回到输入页面.

3.数据绑定

假设有这样的html输入:

    <input type="text" name="name"/>
    <input type="text" name="number"/>
    <input type="text" name="price"/>
   
 下面是NewTopic中execute的方法全部:  
 
 public String execute(WebParam param, VelocityView view)
 throws ServletException, IOException{
  System.out.println(getName());
  System.out.println(getNumber());
  System.out.println(getPrice());
  System.out.println(getLength());
  return "/success.html";
}
   
自动从request注入parameter,这也是Struts DynamicActionForm的好处之一。
不过这里实现更类似多了类型转换的<jsp:setProperty name="bean" property="*"/>
因为Name的类型是String,Number的类型是Integer,Price的类型是float,length的类型是double.至于其他复杂的类型,也许jsf的转换器是个更好的主意。
这样就初步解决了数据的输入绑定和验证。余下的就是业务逻辑的问题。

4.如何操作Session中的信息
 
 获取session中的信息:

  @FromSession(
     sessionKey=User.key
     )
 public void setCurrentUser(String currentUser) {
  this.currentUser = currentUser;
 }

 信息保存到session中: 

  @ToSession(
      sessionKey = User.key  
    )
 public String getName() {
  if(login())return name;
  else return null;
 }

 这2个方法定义在WebAction的实现类中。
 框架在execute()之前执行@FromSession动作，在execute()之后执行@ToSession动作。
 这里使用了annotation,所以要求必须是jdk5.0以上版本.
 
 5.1 Velocity
  waterfall启动时候自动在WEB-INF目录下寻找并初始化Velocity.properties文件
 操作:
 public String execute(WebParam param, VelocityView view)
 throws ServletException, IOException{
  view.addElement("msg","Hello");
  view.go("index.vm");
  return null;
}

ServletAPI对HTTP协议进行了封装,通过配置Web.xml来把不同的请求转发给不同的servlet来处理。Web框架则用一个ActionServlet，根据自己的对Action的定义来转发请求。
抛开那些繁琐的配置文件，设想一下这样一种方法:

1.Web动作的处理和响应

假设这样一个POST请求:

< form  action ="logic/group/NewTopic"  method ="post" >

Web动作实现Bean:

org.qqsns.web.logic.group.NewTopic

注意后面的logic/group/NewTopic和logic.group.NewTopic, 动作类和Web动作是通过请求路径和包名相互关联。
这样，对Web动作的响应就依赖于编译期的代码的组织结构而不是执行期的配置文件。这样的好处是避免了维护繁琐的配置文件,特别是在没有IDE支持的情况下。

org.qqsns.web.logic.group.NewTopic类是一个实现net.wff.servlet.WebAction接口的POJO，下面是NewTopic中execute的方法片段:   

// Only method must be implemented for interface net.wff.servlet.WebAction
  public  String execute(HttpServletRequest request, HttpServletResponse response)
  throws  ServletException, IOException {
  
   // return "redirect /success.html";   // 请求重定向
   return   " /success.jsp " ;               // 请求转发
}

 execute方法的返回值手动指定了一个转发或重定向的路径。

2.输入验证

普通的Web框架都带数据输入验证功能,一般复杂程度和功能强大与否成正比。
这里简单地要求从setter方法里抛出一个包含验证信息的异常，以此来实现输入异常处理。
      
普通setter方法

public   void  setName(String name) { 
   this .name  =  name;
}

添加输入验证后的setter方法

public   void  setName(String name)  throws  InputException {    
  if (name.length() < 3 )
     throw   new  InputException( " Topic name must has a length greater than 3 " ); 
   this .name  =  name;
}

WaterFallServlet是如何处理验证信息的:

WebAction wa  =  
    (WebAction)Class.forName(classPath).newInstance();
           // procces forwarding
           try   {
    ActionHelper.setProperties(request,wa);
   }   catch  (InputException e)  {
     // return to input view
     // header:referer
    String rtn  =  request.getHeader( " referer " );
     // clear old errors
     if (rtn.indexOf( " ? " ) != 1 ) {
     rtn  =  rtn.substring( 0 ,rtn.indexOf( " ? " ));
    }
    rtn = rtn + " ?error= " + URLEncoder.encode(e.getMessage(), " UTF-8 " );
    response.sendRedirect(rtn);
     return ;
   }

这样验证信息通过请求参数传回到输入页面.

3.数据绑定

假设有这样的html输入: 

< input  type ="text"  name ="name" />
< input  type ="text"  name ="number" />
< input  type ="text"  name ="price" />

 下面是NewTopic中execute的方法全部:   

public  String execute(HttpServletRequest request, HttpServletResponse response)
  throws  ServletException, IOException {
  System.out.println(getName());
  System.out.println(getNumber());
  System.out.println(getPrice());
  System.out.println(getLength());
   return   " /success.html " ;
}

自动从request注入parameter,这也许是很多人喜欢Struts DynamicActionForm的原因之一。
不过这里实现更类似多了类型转换的<jsp:setProperty name="bean" property="*"/>
因为Name的类型是String,Number的类型是Integer,Price的类型是float,length的类型是double.至于其他复杂的类型,也许jsf的转换器是个更好的主意。
这样就初步解决了数据的输入绑定和验证。余下的就是业务逻辑的问题。WaterfallWebFramework源代码:
http://www.blogjava.net/Files/zqc/WaterfallWebFramework.rar (只有一个配置文件,其中只有1行配置信息!)

以上就是框架的主要功能。用编码规定代替配置文件，也许这会是一种更加高效率的开发方式。