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


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)

zXing into Android for Barcode reading functionality (original project 100Mb, imported 3Mb)


The zXing documentation is rather complex. A simple task of integrating the zXing library can be painful. Here I am trying to document the steps needed for including zXing as part of your android application.

We have 2 choices. Either to include all the source as part of the android application project itself, or create a new project and import relevant files into this new project. Obviously if you create a new project we need to add the zxing project as a dependent project to your android app project.

This is what I did and things worked for me. I was able to only include 3Mb worth files, instead of the entire 105 Mb.
– checkout the sources from (using svn) http://code.google.com/p/zxing/source/checkout
– Use svn export on the checkedout project, so that you dont get the .svn folders (if u miss this step, you will not be able to import this project into your svn server)
– Create a new java project
– Right click on src directory and hit import
– Select only the “src” sub directory of the following zXing project directories
* core
* javase
* android
* androidtest
* android-integration
– Do not import the test directories from core/javase/android/androidtest/android-integration at first. Do the src imports, get things to work and then play around with test (the same way you did the src).

In your AndroidManifest.xml

In your button click

Intent intent = new Intent("com.google.zxing.client.android.SCAN");
intent.putExtra("SCAN_MODE", "QR_CODE_MODE");
intent.putExtra("SCAN_MODE", "ONE_D_MODE");
intent.putExtra("SCAN_MODE", "PRODUCT_MODE");
myAndroidAppActivity.startActivityForResult(intent,0) ;

In your response listener (source of below code snippet, http://stackoverflow.com/questions/2050263/using-zxing-to-create-an-android-barcode-scanning-app)

public void onActivityResult(int requestCode, int resultCode, Intent intent) {
if (requestCode == 0) {
if (resultCode == RESULT_OK) {
String contents = intent.getStringExtra("SCAN_RESULT");
String format = intent.getStringExtra("SCAN_RESULT_FORMAT");
// Handle successful scan
} else if (resultCode == RESULT_CANCELED) {
// Handle cancel

Q : Getting multiple errors in the src directory of my new project. The import changed the package name to something like “android.src.com.google……”.
A1 : While you import you need to “right click” on the “src” folder of your new project. And hit import. You may have selected import on your project instead of the “src” folder.
A2 : While importing you may have selected the folder “android”, instead of “android/src”.

ObjectInputStream / ObjectOutputStream java and sockets


This is to give generic advice to people writing code that has Object level streaming on sockets. I went thru some pain to get my piece of code working and by this blog I hope to give some quick tips to you.

Tip 1 ) If you expect to read/write objects between a client to your server, then create just one objectoutputstream and outputstream on your client. Similarly create just one objectinputstream and inputstream on your server for that client. Many code fragments will give you reason to believe that you need to create a objectinput/outputstream for every message that you pass. No, you dont. Its wasteful and not needed. Moreover it will return a java.io.StreamCorruptedException: invalid type code: AC exception. AC being the header that is passed from outputstream to inputstream. The inputstream expects only one header for that stream. And the constructor of outputstream creates that :). Sorry, went too deep..

Tip 2 ) If you are doing so much of sockets, I am sure you are using a threadpool to ensure that you dont get screwed on perf. So watch what you lock in a synchronized block. Most often you have locked even the “processing” of data that you received on your objectstream. All you need to have in your sync block is your wait’s, notifies, your calls to add/remove data from the shared queue. Everything else should be outside the sync block. Remember if you are using a threadpool, you are using a shared queue, and all your threads need access to that sharedqueue, so release it asap.

Tip 3 ) Exception handling :). You thought u got a hold on it. Nope. it can be really crazy if you dont. Do some thinking here. You dont want to do a generic, printstacktrace on all. You want “handle” errors correctly. Infact this starts of a new discussion. You need a errormanager framework that handles errors for you. I know, it becomes crazy when you have 10+ dev’s and none of them know how to handle errors. I’ll share some tips to help centralize and control that issue. If you are interested to know more, put some commends on this blog, so that I know its worth my time.. :).

Tip 4) Documentation and Coding. I read some good articles recently which hinted at documenting/commenting only the why’s and not the how’s and what’s.

Tip 5 ) Create all your threads upfront. Dont create threads as and when you get client requests. Remember, clients expect quick response, if multiple clients are going to get alive at the same time, you dont want your server waiting for cpu time to create threads. It will slow down all the clients.

Tip 6 ) EOFException peekByte. Most probably you dont have a InputStream ready. Remember readObject is a blocking call. You dont need to call inputStream.available() to check if there are bytes.

Why handle exceptions ?


As you grow in your career you come to realize that people dont handle exceptions well. No matter how much you guide them, its just done. To be honest with you, its not a problem with them. Correct and easy guidance is missing. Without the right guidance, a dev has the following behaviours
– try catch is a pain
– i do it only if the api i am calling wants me to
– i totally avoid written a exception of my own
– i catch “Exception”
– i’ll clean this up later, now I need to get this code checked in and delivered, its really late.

These are all symptoms, not the root cause of the problem.

The root cause is,
– I dont know how try catch helps me in coding
– If I write my own exceptions, what benefit do I get
– I dont see a reason to know why this is important now, I can do it later

My guidance to them is 2 fold,
– Encouragement
– Skill

– Exceptions to be thrown if we want to communicate to a developer that he has done something wrong with your code. For example, you have written a base class that expects certain data from the derived class. At the point of using that data, you should throw a null pointer exception if that data is null.
– Exceptions are “communication”‘s to developers, NOT to customers. Ideally all unit tests should cover catching exceptions.
– Your fellow developers should know immediately that a nullpointer exception on a variable means that they should have initialized it before using it.
– As a good developer, you generally write code that needs to be written only once, the first time. You dont have the habit of postponing quality for excuses. Once people see that your code works really well, they will start giving you the time you need to deliver quality code. So “dont give in to pressure”.
– When confused, ask your self. Does this error need to be seen by a customer or your fellow developer. If its customer, then show a error message, and end gracefully. If fellow developer, then throw a exception.

Hope this article gave you some indication and guidance.