锘??xml version="1.0" encoding="utf-8" standalone="yes"?> Figure 1 Test Code Structure Each test implementation could be divided into four layers, this structure could help us improve the codes reusability and maintainability, So, it will make us implement the tests quickly and easily. Specification/Scenario layer: This layer describes system’s behaviors and functionalities by the scenarios. For using JBehave, we can use the natural language describe the scenarios and just need to follow the JBehave ‘Given-When-Then’ rule. Parser layer: We don’t need to implement this layer , this layer has been implemented by JBehave. What exactly JBehave do is to relate the steps of the scenario to the methods of the test codes. Step Logic Layer: The layer implements test logics associating with every step of the scenarios. Every step are implemented by a Java method. Action/Utils layer This the very important layer to improve the reusability of our codes. This layer provides the utility methods to help you implement step logics. These utility methods usually involved the system state checking, mock requests sending and so on. For example, we can provide the methods to check the data in database/file or check the state of the middleware, also so frameworks are very useful to implement the logic simulating the client browser’s requests. Working for Amazon.com chaocai2001@yahoo.com.cn
(ns SICP.unit3)
(some #(= col %) s)
)
(defn conflictInDia? [s col]
(let [dia (count s)
n1 (fn [c] (Math/abs (- dia (.indexOf s c))))
n2 (fn [c] (Math/abs (- col c)))]
(some #(= (n1 %) (n2 %)) s)
)
)
(defn safe? [s col]
(not (or (conflictInCol? s col) (conflictInDia? s col)))
)
(defn next-level-queens [solutions-for-prev-level board-size current-level]
(let [solutions (atom [])]
(doseq [s solutions-for-prev-level]
(doseq [col (range 0 board-size)]
(if (safe? s col)
(reset! solutions (cons (conj s col) @solutions))
)
)
)
(if (< current-level (dec board-size))
(recur @solutions board-size (inc current-level))
(count @solutions)
)
)
)
(defn queens [board-size]
(next-level-queens (apply vector (map #(vector %) (range 0 board-size))) board-size 1)
Chao Cai (钄¤秴錛?br />Sr. SDE
Amazon
]]>Source Code
2 ;You could use the code anyway, but should keep the comments
3 ;Created 2012.10
4 (ns clojure.ccsoft.xml
5 (:require [clojure.xml :as xml]))
6
7 (import '(java.io StringReader)
8 '(java.io ByteArrayInputStream))
9
10 (defn xml-structure [xml-txt]
11 [ (xml/parse (-> xml-txt
12 (.getBytes)
13 (ByteArrayInputStream.)
14 )
15 )]
16 )
17
18 (defn node [tag xmlStruct]
19
20 (first (filter #(= (:tag %) tag) (:content xmlStruct)))
21 )
22
23 (defn node [path xml-txt]
24 (loop [path path
25 xml-content (xml-structure xml-txt)
26 ]
27 (let [current-tag (first path) current-elem (first xml-content)]
28 (if (= (:tag current-elem ) current-tag)
29
30 (if (= (count path) 1)
31 current-elem
32 (recur (rest path) (:content current-elem ))
33 )
34 (if (> (count xml-content) 1)
35 (recur path (rest xml-content))
36 )
37 )
38 )
39 )
40 )How to Use
<header>
<type>script</type>
<transaction_id>12345</transaction_id>
</header>
<body>
println 3+4;
</body>
</command>")
(node [:command :header :transaction_id] cmd-example)
]]>
(ns queens)
Chao Cai (钄¤秴錛?/div>
Sr. Software Dev Engineer
Amazon.com
]]>
@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.METHOD)
@Inherited
public @interface NeedToRetry {
Class<?>[] recoverableExceptions();
int retryTime();
int intervalIncrementalFactor() default 0;
long retryInterval() default 0L;
}
2 The Aspect
@Aspect
public class InvokingRetryInterceptor {
private static Logger log = Logger.getLogger(InvokingRetryInterceptor.class);
private boolean isNeedToRetry(Throwable t,Class<?>[] recoverableExceptions){
String exceptionName= t.getClass().getName();
for (Class<?> exp:recoverableExceptions){
if (exp.isInstance(t)){
return true;
}
}
log.warn("The exception doesn't need recover!"+exceptionName);
return false;
}
private long getRetryInterval(int tryTimes,long interval,int incrementalFactor){
return interval+(tryTimes*incrementalFactor);
}
@Around(value="@annotation(amazon.internal.dropship.common.NeedToRetry)&&@annotation(retryParam)",argNames="retryParam")
public Object process(ProceedingJoinPoint pjp,NeedToRetry retryParam ) throws Throwable{
boolean isNeedTry=true;
int count=0;
Throwable fault;
Class<?>[] recoverableExceptions=retryParam.recoverableExceptions();
int retryTime=retryParam.retryTime();
long retryInterval=retryParam.retryInterval();
int incrementalFactor=retryParam.intervalIncrementalFactor();
do{
try{
return pjp.proceed();
}catch(Throwable t){
fault=t;
if (!isNeedToRetry(t,recoverableExceptions)){
break;
}
Thread.sleep(getRetryInterval(retryTime,retryInterval,incrementalFactor));
}
count++;
}while(count<(retryTime+1));
throw fault;
}
}
]]>
]]>
The followings will introduce how to use the JBehave in your real project effectively.
Chao Cai
]]>
1 TDD is design process; it let you design for testing, naturally
Write the test firstly, it does not only help you find the bugs; but the most important point is to let you design for test naturally.
Also you should keep in mind, tests not only help you find bugs, but also protect your codes; when some changes impact on your existing codes, the tests will be broken.
2 Keep the implementation simple
Keep your implementation simple, just let the test pass. The complex implementation may introduce the logics or codes not covered by the tests, even leads some codes not testable.
3 TDD in each scope.
You may get to know the concept ATDD (acceptance test driven development). TDD could be used in every phase of the development and by the different granularity.
To ATDD, you could consider on using some existing framework such as FIT, these frameworks will be bridge between business logic and implementation logic.
Recently, the concept BDD (behavior driven development) is introduced to the ATDD process, so the BDD frameworks such as JBehave is also the good choice.
Different TDD process could be nested and should be nested don’t let your step too large.
4 keep each step small enough
Always keep each step small to avoid introducing the untestable codes or logics and pass each test quickly.
6 Always refactor
This step is always overlooked in TDD process; however it is the very important step. Also, never forget refactor should involve all your tests.
Why can't write test firstly?
1.not think how to meature the codes
2. The current step maybe too large, should separate into small ones
3. The codes with ugly dependencies
http://blog.csdn.net/chaocai2004/archive/2011/01/09/6125479.aspx
Chao Cai (钄¤秴)
Sr. SDE
Amazon.com
浠ュ墠鍦ㄥ涔?fàn)绠楁硶鍜屾暟鎹l撴瀯鐨勬椂鍊欙紝瀵逛簬姣忕綆楁硶鐨勫鏉傚害閮芥槸姝昏鐨勫茍娌℃湁鐪熸鐨勫幓鐮旂┒浠栦滑鏄浣曡綆楀嚭鏉ワ紝鏈榪戠獊鐒跺綆楁硶浜х敓浜?jiǎn)鍏喘懀锛寴q嬌鑷繁鐮旂┒浜?jiǎn)涓涓嬬畻娉曞鏉傚害鐨勮綆楁柟娉曘?/span>
姒傚康
澶?/span>O琛ㄧず娉曡〃紺烘椂闂村鏉傛э紝娉ㄦ剰瀹冩槸鏌愪竴涓畻娉曠殑鏃墮棿澶嶆潅鎬с傚ぇO琛ㄧず鍙槸璇存湁涓婄晫錛岀敱瀹氫箟濡傛灉f(n)=O(n)錛岄偅鏄劇劧鎴愮珛f(n)=O(n^2)錛屽畠緇欎綘涓涓笂鐣岋紝浣嗗茍涓嶆槸涓婄‘鐣岋紝浣嗕漢浠湪琛ㄧず鐨勬椂鍊欎竴鑸兘涔?fàn)鎯〃绀哄墠鑰?/span>銆?/span>
鍙﹀闄や簡(jiǎn)榪欎釜瀹樻柟姒傚康錛屼釜浜鴻涓哄ぇO琛ㄧず鐨勬槸闂瑙勬ān鍜岀畻娉曚腑璇彞鎵ц嬈℃暟鐨勫叧緋匯?/span>
浠ヤ簩鍒嗘煡鎵句負(fù)渚嬶紝鎴戜滑姹傝В瀹冪殑鏃墮棿澶嶆潅搴?/span>
1 璁捐妯′負(fù)n涓厓绱犳椂錛岃鎵цT(n)嬈?/span>
T(n)=T(n/2)+1
T(n)=[T(n/4)+1]+1
…
T(n)=T(n/2^m)+m
褰?/span>n=2^m
T(n)=T(1)+log2n
T(1)=1
鎵浠ュ叾綆楁硶澶嶆潅搴︿負(fù)O錛坙og2n錛?/span>
1 浠?/span>EAR褰㈠紡閮ㄧ講
灝?/span>CXF鐨勫簲鐢ㄤ互WAR鐨勫艦寮忓寘鍚湪EAR涓紝鍦?/span>EAR鐨?/span>META-INF涓殑閰嶇疆鏂囦歡application.xml涓0鏄庝綘鐨?/span>WAR錛屽茍鍦?/span>weblogic-application.xml涓姞鍏ヤ互涓嬪唴瀹癸細(xì)
<?xml version="1.0" encoding="UTF-8"?>
<weblogic-application xmlns="http://www.bea.com/ns/weblogic/90">
<application-param>
<param-name>webapp.encoding.default</param-name>
<param-value>UTF-8</param-value>
</application-param>
<prefer-application-packages>
<package-name>javax.jws.*</package-name>
</prefer-application-packages>
</weblogic-application>
榪欎釜閰嶇疆鏄憡璇夊簲鐢ㄦ湇鍔″櫒鐨勭被瑁呰澆鍣ㄥ浜庤EAR鑰岃█浼樺厛浣跨敤璇?/span>EAR涓?/span>javax.jws.*鐨勫疄鐜般?/span>
2 鍦ㄥ簲鐢ㄦ湇鍔″櫒鍚姩鏃跺姞鍏?/span>Java VM鍙傛暟
-Djavax.xml.soap.MessageFactory=com.sun.xml.messaging.saaj.soap.ver1_1.SOAPMessageFactory1_1Impl
濂戒簡(jiǎn)鐜板湪涓鍒囨悶瀹氾紒
(钄¤秴 chaocai2001@yahoo.com.cn)