Mobile Application testing (functionality and performance) Junit TestSuite

0

Self Advertisement
—–Start of Advertisement——-
BUILD CAR POOL SOLUTIONS ON ANY DEVICE TO RUN ANYWHERE (www.mcruiseon.com). Introducing mCruiseOn, the java library /json api’s that you can use to build a car pool solution. Be the next avego.com, carpooling.com, zimride.com. mCruiseOn is your one stop API on EC2.
——End of Advertisement——-

The world of mobile applications is growing into a new era, where large databases are being provisioned via webservices to enable increased productivity via mobility. These applications are following the 2 tier approach, of UI and a WebServices client layer.

It is becoming a common practice to use webservices and provide a seamless experience on the mobile application. Various techniques to fetch, pre-fetch, cache and lazy load are used to provide that seamless experience. Teams working across the world are more common. Webservices team are generally closer to business, closer to business data that is proprietary and heavily guarded. Client teams in-turn are located in offshore centers, and their development is provisioned by VPN’s, api stubs (dead data, until the webservice is developed).

Projects too have a common feel to it. Applications start their work with UI and write their api calls on dead data stubs. This happens in parallel to web service teams developing their api’s. Changes are communicated to the app team (hopefully such agreements have been reached). The app team develops their UI along side with dead data on api stubs.

Typically test teams too are integrated by now and are testing the UI (with the dead data). But it is interesting to know that test teams can contribute big time by helping eliminate a future threat to their productivity. The basis of their preparation can also be used to test the webservices for performance.

Think about it. If the test team was able to call a webservice api, check its return values and verify if the api’s are returning what they are expected to, at the right place. Now, the question that comes to your mind is, How will it help the team to test the webservice and its location of data. Well, let me explain.

A web service is rarely developed for a particular application. It is more commonly developed for a suite of applications across multiple domains. Every webservice undergoes change constantly with pressure from various applications. So its in their best interest to modify the location of data to suite the needs of all these applications. One change to the location of data, and it will have its side effect on all other teams.

The question is, why doesn’t the webservice team behave proactively and communicate to all its clients about these changes in advance. Well, most of it is political. They communicate to all teams they want to. They don’t communicate to teams they don’t want to.

Side effect, a client app is impacted, and the developer (oblivious to the fact that the god damn api changed), debugs his code and takes that 3-4 hours to figure out it was a api change.

Now, how about if there was a way to identify this change before that developer sits to debug.

Answer is simple. Junit.

Lets collect our tools

  • Eclipse
  • Fiddler (download it, install it)
  • API Documentation
  • Split the API’s into 2 parts
    • dont need login
    • b) need a login
  • Call a api that does not need a login
  • Fire it on Fiddler, copy the JSON (assuming JSON) response
  • Now, using http://code.google.com/p/jsonschema2pojo/ , Hit the http://jsonschema2pojo.org/
  • Paste the json raw response and hit “jar”. Download the jar file.
  • All your files containing the pojo’s will be ready for your use

Now, you need to write your Hello World

File->New->Junit TestCase->In your @Test method write

		JsonNode pubInfo = null ;
		Iterator pubDetails ; 
		HttpURLConnection connection ;
		ObjectMapper mapper = null ;
		JsonNode responseJson = null ;
		try {
			URL url = new URL(
					"Your URL Here");
			connection = (HttpURLConnection)url.openConnection() ;
			connection.setDoInput(true);
			connection.setDoOutput(true);
			connection.setRequestMethod("POST") ;
			connection.setRequestProperty("Content-Type", "application/json") ;
			// and other configuration if you want, timeouts etc
			// then send JSON request
			SpecialBooks request = new SpecialBooks(); // POJO with getters or public fields
			mapper = new ObjectMapper(); 
			mapper.writeValue(connection.getOutputStream(), request);
			// and read response
			responseJson = mapper.readTree(connection.getInputStream());
		} catch (JsonGenerationException e) {
			e.printStackTrace();
			fail() ;
		} catch (JsonMappingException e) {
			e.printStackTrace();
			fail() ;
		} catch (IOException e) {
			e.printStackTrace();
			fail() ;
		}
		assertNotNull(responseJson) ;
		JsonNode pubs = responseJson.get("SpecialBooks") ;
		assertNotNull(pubs) ;
		pubInfo = pubs.get("BookInformation") ;
		assertNotNull(pubInfo) ;
		pubDetails = pubInfo.elements() ;
		assertNotNull(pubDetails) ;
		assertNotNull(pubDetails.next().get("Size").toString().contains(" MB")) ;
Advertisements

Testing for Developers, necessary evil (developers/managers read this)

0

I have always wondered why developers fail to test their own code. It believe its a upbringing issue. If you have worked with people who care a lot about product quality, and value the fact that defects must be found early, you will write and plan unit testing into your development effort. Basically if you have spent time with talented folks you will do what it takes to get your code/design and data model right. You will understand the difference between throwing exceptions and printing error messages on screens. Also the ability to debug your app later will be on your mind.

Also seems like developers get the attitude from their seniors/teachers, who imply that Testing is for idiots, and the fact that they strongly believe that they are the only chosen ones who can do development. Infact I can be sure that developers who dont believe in testing their own code, spend countless hours mocking testers.

Now you can say that the system is to blame. Managers dont care about unit test cases, customers only care about their tests working, ultimately the business managers who care only about “time to market”. Infact so strong is the communication from top, is “time to market” is the only important criteria. Quality is recognized only if “time to market”, estimates and dates are maintained. And every person who had delivered a project knows that “time to market” never takes a hit, its the quality.

To clean up the system it takes someone to start. Developer is just as good as anyone to start.

I wont spend time convincing developers to unit test their code, or to write test cases. But I will spend time to help developers who are convinced about unit testing and guide them thru their challenges.

Challenge No 1 : What to test ?
Every class needs to be tested. A class is testable if you have simple small classes that do just the job they are suppose to do. Keep your classes simple and hence testable.

Challenge No 2 : When to test ?
When you have completed coding of your class. And all methods have clear inputs and outputs.

Challenge No 3 : I am stuck, just cant think.
First get your hands off your computer. Take a pen and pencil and start putting down mind maps, input scenarios, what ever help you think.. THINK!!!! Just collect your thoughts. Personally I use the white board. I put down tables, flow charts, just to collect my thoughts..

Challenge No 4 : What test cases to write
Here you need to refer to the basics of software engineering. Unit test cases is positive tests, negative tests and boundary conditions. Our mind can get easily confused. So lets take this step by step. Start simple, positive test cases. Then negative and finally boundary. If you are as crazy as I am, also do “equivalence partitioning” for data sets that is beyond testing.

Challenge No 5 : I cant think!!!
Yes this is a reality people, developers put in soo much of their analytical thinking while coding, that thinking testing (which is a lateral and destructive thought, is a pain). Creative Thinking uses up the entire brain. Drink water, lots of it. The brain needs oxygen to think, and water is the only way the brain gets its needed oxygen. Take a walk with a pencil in your hand. Just relax and collect your thoughts.

Challenge No 6 : Im still stuck!!
Reply to this blog, lets discuss. You need a mentor and someone to bang your head against, a sound board. I can be that for you. reply.. lets talk it out..

Finally I leave you with this thought.
DO A KICK ASS JOB, not just a job.. “Just Coding” is for idiots.. Its the real men (or women for that matter) who can write test cases..

(This blog helped me gather my thoughts http://stackoverflow.com/questions/83147/whats-wrong-with-foreign-keys, especially comment by Ed Lucas)

Continuous Collaboration with Mingle, SVN, Email and Wiki – Part 1 (Forming)

0

Agile has been around for sometime now. Most use it as a buzz word, not benefiting from its core principles people maturity and and need to extreme communication. This development life cycle is initiated by developers essentially. Think about it. All that CMMi gives you, is a top bottom approach. And since the acceptance of the young generation to agile is just so high, CMMi has to give way. So they just “accept” what you say, and today CMMi is just a certificate with very less value with the young generation.

Obviously just like PMI, CMMi is struggling to prove its point today. That processes are important and if not done the CMMi or PMI way, will fall flat. The fact remains that organizations with PMI and CMMi are falling flat. They no longer do the amount of software development they use to. They now focus their business on “servicing” software products already developed. Basically they could not keep up with the pace. Not their fault in my opinion, just that the pace is too fast for anyone to keep up.

It needs you to think that you are “worthless”, and start studying again. Pick up your database book, design patterns book and programming language book and start writing some code, debuggers, watch’s. Get your head out of excel sheets, ppts and mpp’s :). It is when you dont get your head out and start studying, you realize that you cannot keep up with the pace. And start believing that without CMMi and PMI projects cannot run. Until you get a rude wake up call by a young engineer (but considering the youngsters today, I dont think they care about wasting their time with you). So guys/gals wake up. Get your head out, and into the right things.

So what has this got to do with Continuous Collaboration. Well, everything.

The above was a wake up call for you to realize that today running projects is about collaboration. As a manager if you frequently think, “if the Iteration Manager/Business Analyst will do this, what will I do”, its time for you to wake up (read the first few para’s).

You have to do some real contribution. Martin Flower says it. Write some code (gain respect of your fellow’s). Create a framework that can replace and refactor some dirty code. Reproduce some bugs, play with the interim builds of the product and give valuable feedback. Dont need your tech leads to sit thru all meetings to give feedback to UX. In other words do some real contribution. Ask relevant questions, effectively communicating with lesser words and more diagrams. Do some tech talks. Show them that analytical ability only increases with time and age, and not the other way around.

AndroidTestCase basics

0

A quick blog on its basics. Its a bit crazy to read the developer.android.com site for this. So, you create a AndroidTestCase when you want to test a android application from test cases. So you have a screen with some data, buttons. Your test case will fill in the data, and press the buttons. Infact you can also call methods of your classes.

Now you ask, where will the test case get the application context for that app. Simple, when you set up a project with a class that extends AndroidTestCase, you also need to put in the following to your manifest. The test case launches and loads your applications and you can get a reference to your app context from super.getContext(). Cool ?? I think so..

Test run failed: java.lang.IllegalAccessError

7

This happens when you have 3 projects in your eclipse dev environment.
1) Library project : here you have common stuff between other projects
2) Android project : here you have your android app, which has the Library project as a project in your build path
3) Android Test Instrumentation project : here you have your test cases which run on your android device.

Naturally you will include 1 and 2 as dependent projects to 3, in 3’s properties->java build path -> projects.

Instead you need to edit the project properties on 2. On 2, Properties->JavaBuildPath->OrderandExport, check the Library project for exporting.
AND
Dont include the library project into 3, instead just include 2 in 3. Since 1 is exported in 2, you will be ok. And this error will go away.

I referred to this blog for this issue.

java.lang.RuntimeException: Stub! at junit.framework.TestSuite.(TestSuite.java:7)

10

Self Advertisement
—–Start of Advertisement——-
BUILD CAR POOL SOLUTIONS ON ANY DEVICE TO RUN ANYWHERE (www.mcruiseon.com). Introducing mCruiseOn, the java library /json api’s that you can use to build a car pool solution. Be the next avego.com, carpooling.com, zimride.com. mCruiseOn is your one stop API on EC2.
——End of Advertisement——-

This has been driving me crazy for the last few days. Late nights and my sleep. All I wanted to do was integrate junit early on the project so that I can start unit testing. So my setup is simple, eclipse, java project (writing my server piece), hibernate and junit. Every time I write just a simple

package com.mcruiseon.server.testcase;
import java.util.ArrayList;
import org.hibernate.SessionFactory;
import junit.framework.TestCase;
import org.junit.Test;

public class HibernateConnectionTest extends TestCase {	
	@Test public void testInsertRow() {
		assertEquals(0,0) ;
	}
}

This above code would throw nasty exception

java.lang.RuntimeException: Stub! 	at junit.framework.TestSuite.(TestSuite.java:7) 	at org.junit.internal.runners.JUnit38ClassRunner.(JUnit38ClassRunner.java:67) 	at org.junit.internal.builders.JUnit3Builder.runnerForClass(JUnit3Builder.java:14) 	at org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:57) 	at org.junit.internal.builders.AllDefaultPossibilitiesBuilder.runnerForClass(AllDefaultPossibilitiesBuilder.java:29) 	at org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:57) 	at org.junit.internal.requests.ClassRequest.getRunner(ClassRequest.java:24) 	at org.junit.internal.requests.FilterRequest.getRunner(FilterRequest.java:34) 	at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.(JUnit4TestReference.java:29) 	at org.eclipse.jdt.internal.junit4.runner.JUnit4TestMethodReference.(JUnit4TestMethodReference.java:25) 	at org.eclipse.jdt.internal.junit4.runner.JUnit4TestLoader.createTest(JUnit4TestLoader.java:41) 	at org.eclipse.jdt.internal.junit4.runner.JUnit4TestLoader.loadTests(JUnit4TestLoader.java:30) 	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:452) 	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683) 	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390) 	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)

I googled like crazy, logged bugs with junit, all I could find is issues reported with maven. Finally I hit a bug on junit, and identified the root cause.

Dont smile!!!

Move the junit dependency up the chain on your referenced libraries and it worked :).

Have fun