BlogJava-thinking-随笔分类-Unit Test

java模拟并发操作进行压力测试

lau — Fri, 28 May 2010 03:06:00 GMT

http://www.qqread.com/java/2010/01/c488170.html

import java.io.BufferedReader;

import java.io.File;

import java.io.FileInputStream;

import java.io.InputStreamReader;

import java.io.PrintWriter;

import java.net.HttpURLConnection;

import java.net.URL;

import java.util.HashMap;

import java.util.Map;

import java.util.concurrent.ExecutorService;

import java.util.concurrent.Executors;

import java.util.concurrent.Semaphore;

public class ConcurrentTest {

private static int thread_num = 200;

private static int client_num = 460;

private static Map keywordMap = new HashMap();

static {

try {

InputStreamReader isr = new InputStreamReader(new FileInputStream(

new File("clicks.txt")), "GBK");

BufferedReader buffer = new BufferedReader(isr);

String line = "";

while ((line = buffer.readLine()) != null) {

keywordMap.put(line.substring(0, line.lastIndexOf(":")), "");

}

} catch (Exception e) {

e.printStackTrace();

}

}

public static void main(String[] args) {

int size = keywordMap.size();

// TODO Auto-generated method stub

ExecutorService exec = Executors.newCachedThreadPool();

// 50个线程可以同时访问

final Semaphore semp = new Semaphore(thread_num);

// 模拟2000个客户端访问

for (int index = 0; index < client_num; index++) {

final int NO = index;

Runnable run = new Runnable() {

public void run() {

try {

// 获取许可

semp.acquire();

System.out.println("Thread:" + NO);

String host = "http://10.99.23.42:7001/KMQueryCenter/query.do?";

String para = "method=getQueryResult&pageNum=1&pageSize=5&"

+ "queryKeyWord="

+ getRandomSearchKey(NO)

+ "&questionID=-1&questionIdPath=-1&searchType=1"

+ "&proLine=&proSeries=&proType=" + NO;

System.out.println(host + para);

URL url = new URL(host);// 此处填写供测试的url

HttpURLConnection connection = (HttpURLConnection) url

.openConnection();

// connection.setRequestMethod("POST");

// connection.setRequestProperty("Proxy-Connection",

// "Keep-Alive");

connection.setDoOutput(true);

connection.setDoInput(true);

PrintWriter out = new PrintWriter(connection

.getOutputStream());

out.print(para);

out.flush();

out.close();

BufferedReader in = new BufferedReader(

new InputStreamReader(connection

.getInputStream()));

String line = "";

String result = "";

while ((line = in.readLine()) != null) {

result += line;

}

// System.out.println(result);

// Thread.sleep((long) (Math.random()) * 1000);

// 释放

System.out.println("第：" + NO + " 个");

semp.release();

} catch (Exception e) {

e.printStackTrace();

}

}

};

exec.execute(run);

}

// 退出线程池

exec.shutdown();

}

private static String getRandomSearchKey(final int no) {

String ret = "";

int size = keywordMap.size();

// int wanna = (int) (Math.random()) * (size - 1);

ret = (keywordMap.entrySet().toArray())[no].toString();

ret = ret.substring(0, ret.lastIndexOf("="));

System.out.println("\t" + ret);

return ret;

}

}

如果本文对您有帮助并且要鼓励我的话，请扫描如下二维码支持本人的劳动成果，多谢了！

lau 2010-05-28 11:06 发表评论

EasyMock最佳实践

lau — Fri, 21 May 2010 02:56:00 GMT

Source: http://macrochen.javaeye.com/blog/298032

lau 2010-05-21 10:56 发表评论

Fun with EasyMock

lau — Wed, 21 Apr 2010 10:23:00 GMT

Fun with EasyMock

I'm a big fan of Test-driven development and have been using JUnit for 6 or 7 years (since around v3.4 or v3.5). I've written lots of mock objects (from simplistic dummy concrete classes that implement an entire interface, to Proxy-based mocks, to a pretty decent mock JMS library) and played with various mock libraries, but the one I'm sticking with and using almost exclusively is EasyMock.

Reinventing a wheel is great for learning, and I've done it a lot. But perhaps in a sign that I'm getting older, I'm more concerned with getting stuff done, so now I tend to lean towards existing solutions when good ones exist. I searched for what people tend to use for mock objects and jMock and EasyMock are popular. I prefer the method-based approach of EasyMock to the string-based approach of jMock, since code changes will cause the tests to break immediately, and the mocks will be refactored along with the rest of the code if I use the IDE's refactoring features.

The general pattern with creating mocks for a tier of your application is that you're trusting that that tier is tested and works correctly, so it's appropriate to have mocks return hard-coded values. We're testing that the caller of the mocked interface does the right thing with correct (or incorrect) inputs, so mocks help us to focus on what's being tested in isolation.

I'd always found it difficult to unit test Spring MVC controllers, since it seems like they need a running container, and I don't want to deal with the hassle of setting up Cactus. Plus it seems somewhat useless to test controllers, since they shouldn't be doing much that isn't tested in proper automated functional tests. If they do too much business logic, they should be refactored to push that work out to the services layer, right?

The reality is that we do too much business logic in controllers, and usually it's lazyness but often it's being pragmatic. We also tend to often do even more "illegal" activities in controllers, such as writing directly to the response rather than delegating to a View. This is usually the case for XML and JSON generated for Ajax responses. So until these get refactored, they need to be tested.

It's helpful to have partially-functioning servlet container classes such as HttpServletRequest and HttpServletResponse, and the Spring Mock library (spring-mock.jar) is great for that. But for creating mocks for DAOs, services, and other interface-based dependency-injected resources, EasyMock greatly simplifies things. And with their user-contributed Class Extension, you can even mock out concrete classes.

The syntax takes a while to get used to. Basically the flow that I tend to use is:

Create a mock
call expect(mock.[method call]).andReturn([result]) for each expected call
call mock.[method call], then EasyMock.expectLastCall() for each expected void call
call replay(mock) to switch from "record" mode to "playback" mode
inject the mock as needed
call the test method
call verify(mock) to assure that all expected calls happened

As simple as that may sound, it can look very weird at first. Say I have an interface:

PLAIN TEXT

JAVA:

public interface Thing {
void doSomething(String parameter);
int doSomethingElse(String parameter, int otherParameter);
}

I can create a mock for it via:

PLAIN TEXT

JAVA:

Thing thing = EasyMock.createMock(Thing.class);

Then I can register expected calls via

PLAIN TEXT

JAVA:

EasyMock.expect(thing.doSomethingElse("woot", 5)).andReturn(123);
EasyMock.expect(thing.doSomethingElse("fubar", 45)).andReturn(321);
thing.doSomething("p");
EasyMock.expectLastCall();

This says that in my calling code, when the client calls thing.doSomethingElse("woot", 5) to return 123, when the client calls thing.doSomethingElse("fubar", 45) to return 321, and to expect a call to thing.doSomething("p").

I can then inject this mock into the class being tested in place of the real one, trusting that it will return known results. I can then concentrate on assuring that the tested class does the right thing.

Thanks to EasyMock, my productivity for testing services and controllers is way up - and my code coverage percentages are too.

This entry was posted on Monday, August 13th, 2007 at 2:43am and is filed under easymock, java, junit. You can follow any responses to this entry through the RSS 2.0 feed. You can skip to the end and leave a response. Pinging is currently not allowed.

Source from http://burtbeckwith.com/blog/?p=43

lau 2010-04-21 18:23 发表评论

Mock void method

lau — Wed, 21 Apr 2010 10:23:00 GMT

I have a method that returns void in a class that is a dependency of the class I want to test.

This class is huge and I'm only using this single method from it. I need to replace the implementation of this method for the test as I want it to do something different and I need to be able to access the parameters this method receives.

I cannot find a way of doing this in EasyMock. I think I know how to do it with Mockito by using doAnswer but I don't want to add another library unless absolutely necessary.

If I understand what you want to do correctly, you should be able to use andAnswer():

mockObject.someMethod(eq(param1), eq(param2);

expectLastCall().andAnswer(newIAnswer(){
    publicObject answer(){
        //supply your mock implementation here

        SomeClass arg1 =(SomeClass) getCurrentArguments()[0];

        AnotherClass arg2 =(AnotherClass) getCurrentArguments()[1];

        arg1.doSomething(blah);

        //return the value to be returned by the method (null for void)

        returnnull;

    }

});

lau 2010-04-21 18:23 发表评论

Mocking Static Calls

lau — Thu, 25 Feb 2010 01:12:00 GMT

How can you test methods that contain static method calls? This is a question we're facing at the moment while working on an application of which parts have been written by another development team. In order to gain insight into functionality and quality of the codebase, we are writing JUnit tests. But a lot of the code is dependent on either the JSF FacesContext or the Spring ApplicationContext being available.

It is however impossible to mock static method calls like FacesContext.getCurrentInstance(). So how do we go around testing these calls out of container? We've thought up three different approaches, but each has its pros and cons. Let us first take a look at these three approaches...

1. Extract method
Introduce a method in each class that looks like the following:

 

protected FacesContext getFacesContext() {

return FacesContext.getCurrentInstance();

}

This can be easily mocked out in your test by creating the class with an overridden method, as follows:

 

FacesContext mockContext = EasyMock.createMock(FacesContext.class);

new MyObjectUnderTest() {

protected FacesContext getFacesContext() {

return mockContext;

}

}

Pros

Easy to refactor using extract method

Cons

Lots of code duplication

2. Static Helper
Our second option is to introduce a static helper class which has the following implementation:

 

public class FacesContextHelper {

private static FacesContext context;

 

public static FacesContext getCurrentFacesContext() {

return context != null ? context : FacesContext.getCurrentInstance();

}

 

public static void setFacesContext(FacesContext facesContext) {

context = facesContext;

}

 

public static void reset() {

context = null;

}

}

Now in a testclass we can just write down the following line to mock out the FacesContext:

 

FacesContextHelper.setFacesContext(EasyMock.createMock(FacesContext.class));

Pros

No real painful code-duplication
Easy to do search-replace to convert all calls to FacesContext.getCurrentInstance() to FacesContextHelper.getCurrentFacesContext().

Cons

Never forget to call reset() in the teardown of your test to prevent another test from picking up your mock.
Doesn't feel right to write static setter methods in your code just to enable testing it. Not an OO approach?

3. OO Helper class
Our third and last option is to introduce an interface and implementation of the FacesContextHelper:

 

public interface FacesContextHelper {

FacesContext getCurrentFacesContext();

}

 

public class FacesContextHelperImpl implements FacesContextHelper {

public FacesContext getCurrentFacesContext() {

return FacesContext.getCurrentInstance();

}

}

We now need to introduce an instance of the FacesContextHelperImpl to each class. For this example, we will use a package protected variable in each class. It is of course also possible to use a setter method. For our test cases we now need to introduce a new FacesContextHelper:

 

public class MockFacesContextHelper implements FacesContextHelper {

private FacesContext mockContext;

 

public MockFacesContextHelper(FacesContext mockContext) {

this.mockContext = mockContext;

}

 

public FacesContext getCurrentFacesContext() {

return this.mockContext;

}

}

In our test cases we can now easily mock out the FacesContext again by setting the package protected field:

 

someClazz.facesContextHelper = new MockFacesContextHelper(EasyMock.createMock(FacesContext.class));

Pros

Feels more natural and OO than the static helper solution

Cons

Need to introduce a new field to each and every class which needs the FacesContext mocked out.

That's it. I myself am still doubting as to which method is the lesser evil, not one feels absolutely right. What do you think, which method do you consider better? Did I overlook another option perhaps?

lau 2010-02-25 09:12 发表评论