Integrated Mockito TestNG and Emma on an ant built (Targeted for Java developers who aim TDD)

I have prepared a very simple sample ant project showing how to integrate and run Mockito, TestNG and Emma projects. For those of you who wonder what these projects are, Mockito is Java Mock framework, TestNG is Unit Test Case Framework and Emma is the code test coverage tool.

The purpose of this project is to demonstrate how ClassThatOutputsHelloMessage is tested with TestNG. How NameProviderInterface is mocked with Mockito and how is the Mockito syntax written in TestNG test case. Showing dependency injection = Giving NameProviderInterface as ClassThatOutputsHelloMessage constructor argument. And what kind of code coverage report you obtain with emma.

Inorder to see the sample checkout my experimental stuff rep with hg(mercurial client)

hg clone https://barisergunexperimentalstuff.googlecode.com/hg/ barisergunexperimentalstuff

And than, navigate to testngmockitosimplesample folder. And run the below ant command:

ant runtestswithemma

If everything is okey you will see a generated folder named coverage. Inside this directory you will see 3 different formats of report(html,xml,txt). Especially check the html format to easily navigate the report to see which lines of code is not tested.

At the begining you will see that not all of the code is tested. In the ClassThatOutputsHelloMessageTest.java source Uncomment the commented-out test case. And re-run tests with emma. Check and verify that the coverage report has changed with %100 coverage.

Please place a comment here on this blog if you face any problems.

Things to remember:

Make sure your environment variable JAVA_HOME is set. When you try to integrate these tools to your own project keep in mind that you should compile your sources with debug="on" option in order to be able to see the line coverage of your codes with emma instrumentation.


Blogs that helped me:
http://rwatsh.blogspot.com/2008/03/using-testng-with-emma-for-automating.html

Imagine how Test Driven Development helps you.

I decided to write this article to be able to provide a general understanding about test driven development and how it may help you. When I am talking about the subject I will refer to bugs as real world bugs like a single fly or a mosquito etc. and Testing approaches as weapons used to kill them ie. smashing, electrical killers or an axe (well can you kill a mosquito with an axe, theoretically yes you can; yet we will see the results ;)) I will number these testing approaches from 1 to 3 and finally return back to the real world mosquito scenario.

1-) Unit Testing with Mock APIs: (SMASH)

Lets start with unit testing and mock APIs around them. When we need to talk about unit testing keep in mind there other concepts such as Fake APIs as well. Well to give you an understanding about the difference of these 2 approaches:

a-) For Mock API you can use mock frameworks such as (Mockito for Java Google Mock for C++) and all you will have to do is write the behavior of your mocked API during your Unit Test cases as pre-compiled expectations and you will spend no or minimum (minimum for Adapting API implementations) effort on implementing the mocked api. Because mock framework does the implementation for you, or better to say; mock framework provides you an API as if there is a real API interacting with your unit or module under development.

b-) Fake API approach is much more time consuming approach for a developer. Because based on your real API you have to implement a "Fake API" which behaves like your real API and you will have to provide switch like structures to manipulate the behavior of the implemented fake api.

Well considering from development point of view; mock approach seems much more reasonable compared to the fake approach. But you have to be careful about the design of your software module if you follow the mock approach. The mock approach requires you to provide a visibility for 3rd party APIs from out of your implemented module. Here the Dependency Injection is the remedy for such design considerations which I will discuss about on another article.


Pros:
- Isolation of development modules completely from each other during design.
- Unit tests for a module run in seconds or mseconds.
- You can find simple bugs early in the development cycle.
- Maintenance and refactoring efforts of the software module is significantly reduced.
- The developer is more confident about his software modules.
- You do not need a test bed.
- The unit tests can be %100 percent automated.

Cons:
- Development effort of software developer may have been doubled during the initial development. (considering reduction of maintenance efforts in later cycles this negative affect is balanced in whole life cycle of the software module).
- Another designing requirement of the software module rises such as "Design From Test Point Of View".


2-) Integration Testing:(ELECTRICAL BURNER FOR KILLING INSECTS)

Now that each software module has been developed in an isolated kind of approach, it is time to bring them together or all together and see the affects of them on each other. There are some commercially available tools beside home made integration test frameworks which software developers can use for such purposes. You can think of this stage as replacing the mock apis (during unit tests) with real implemented modules by other developers. Generally an integrator such as the technical leader of the project drives this effort. I have an important suggestion here: INTEGRATE OFTEN such as once an every week or every two weeks. Because other wise it will be hard to keep in line regarding the major changes during development.

Pros:
- Gives you the ability to trace undesired affects of the integrated modules on each other, before releasing an alpha version of your product.
- Good approach for locating hard to find bugs.
- Confirms that specifications and protocols are doing fine in coordination.

Cons:
- Takes more time than a unit testing such as minutes or more depending on your environment
- Requires you to provide a real test bed with real software and hardware units.
- Harder to automate compared to Unit Tests because there may be many dependencies from outer world such as (Dbs, Network conditions etc....)


3-) Black Box Testing: (AXE)

This is actually a very large topic including sub headers such as Regression, Functional, Stress etc. tests . So from a developer point of view this effort is driven by other people, tools or organizations such as Manual and/or Automated Test Engineers, 3rd party testing organizations, Black Box Automated Test Tools etc. So I will leave you the googling part and just mention about main Pros and Cons.

Pros:
- Overall software product is tested by professional testers in alpha and/or beta cycles before releasing the product to the market.
- In this cycle inconsistencies are diminished from a user point of view.

Cons:
- You really need a good test bed, test setup, automated test environment for black box testing.
- Takes days or even months to test the overall product.

KILLING THE MOSQUITO SCENARIO

- You use the AXE to smash the mosquito after many tries you are very tired, the walls are ruined and the mosquito is still alive and kicking.
- Than you decide to use the ELECTRICAL BURNER, you wait for the sun to settle down and the room is dark you plugin the device and wait for the mosquito, but the mosquito found another light source and made his way along that direction and he never hit the electrical burner. You are very tired and sleepless, the mosquito is still alive and buzzy.
- Than next morning you decide to smash the mosquito on the wall, you are very tired so after many attempts you finally managed to get a bloody spot on the wall.

That mosquito was a NULL POINTER that some how was never hit during your Integration or Black Box tests.


Have a nice day;

Baris ERGUN.

Architechtural Topic: Webinar about Commonality And Variability Analysis.

I have been following this Pattern Oriented Methodology called Commonality And Variability Analysis CVA since last 4 years. I performed CVA just right after Use Case Analysis where a general Use Case of the Software Project were clear. Well it is hard to find Product Managers writing Use Cases so I also had to spend some time on this Use Case Analysis thing based on some valuable information from IBM Rational approaches.

The cycle goes like this. Use Case Analysis -> CVA (High Level Architectural Design efforts)-> Test Driven Implementation -> More Detailed Architectural decisions on the Fly -> Review of CVA before Integration-> write Integration Tests -> Deliver.

Thanks to Net Objectives which makes this webinar available online about CVA I hope you enjoy it.

http://www.netobjectives.com/streamzines/Commonality-VariabilityAnalysis/player.html

For further reading I suggest Copliens Thesis and Design Patterns Explained.

Switch to "NoMachine's" Linux to Linux fast Remote Desktop products (VNC or ssh -X sucks)

- Download the appropriate pacakge for your Linux distro from this link.

- Install Client, Node and Server respectively to your host machine
- Install Client to your remote machine.
- /usr/NX/bin/nxclient and have fun....

Note: Make sure that your sshd is up and running (prerequisite)

Quick guide for using Google Code Repository and Mercurial as the Source Control Tool

1-) Click to this link Code Google and choose Create a New Project Link.

2-) According to directions from Google on the page you read; create your code project and choose Mercurial as your source control tool.

3-) I am using Ubuntu 10.04. I used 'sudo apt-get install tortoisehg' routine to install the hg executable as Mercurial source control client.

4-) hg clone {your_google_code_repository_url}

5-) make the necessary changes in the checkedout directory

6-) hg add {directories or files you desire}

7-) hg commit -u {your_google_account} -m "your commit message"

Remember that commit is a local operation on Mercurial

8-) hg push

In order to sync the changes to your google code repository. When you call this routine you will be asked your google code credentials.

And thats it. Just a very fast tutorial...

Engineering Puzzles | Facebook

Engineering Puzzles | Facebook