Get the Runner here
Monthly Archives: November 2013
JMockit EclEmma Issue
Goto Preferences , Edit JRE
Add JMockit javaagent option
jmockit-versus-powermockito
Mocking framework is a desperate need for a good quality product, it helps develop fast, light and accurate test cases by focusing on business needs.
It all started with EasyMock/JMock, It did not took much time for Mockito to acquire the developer attention, as it was easy to use and with less learning curve. Of course it had its own limitations
Mockito Limitations
- Cannot mock static
- Cannot mock final
- Cannot mock private
- cannot mock constructor
- Mocking is only possible on VMs that are supported by Objenesis.
- Spying on real methods where real implementation references outer
ClassviaOuterClass.thisis impossible.
It wont be a wise decision to modify production code just to satisfy a mocking framework 
PowerMock soon filled the void, emerged out of using Mockito. However it brought in its own caveats.
PowerMock Caveats
- PowerMock does not provide a complete API for mocking, but instead works as an extension to another tool, which currently can be EasyMock or Mockito. This is obviously an advantage for existing users of those tools.
- PowerMock API is more “low-level”, forcing users to figure out and specify which classes need to be prepared for testing (with the @PrepareForTest({ClassA.class, …}) annotation) and requiring specific API calls to deal with various kinds of language constructs that may be present in the production code: static methods (mockStatic(ClassA.class)), constructors (suppress(constructor(ClassXyz.class))), constructor invocations (expectNew(AClass.class)), partial mocks (createPartialMock(ClassX.class, “methodToMock”)), etc.
- PowerMock uses custom class loaders (usually one per test class) in order to generate modified versions of the mocked classes. Such heavy use of custom class loaders can lead to conflicts with third-party libraries, hence the need to sometimes use the @PowerMockIgnore(“package.to.be.ignored”) annotation on test classes.
- Confusion over the same names in both Mockito and PowerMock, for example the when method
- There is no consistent way of doing things, you always have to look for hacks/work around to get things workings
- Many a times error reporting is inconsistent and leads to confusion.
Introducing JMockit
If your frustrated with spending more time just to make a test case working, confusing error messages, and finding hacks to get things working, JMockit is all you need.
JMockit Features
- Mocks
static,final, private, static initializers, enums, annotations and constructors - You always do the things in consistent and preditable ways (No hacks and work arounds)
- Expressive recording & verification API, with elegant and consistent syntax
- Concise argument matchers and argument capturing
- With JMockit Expectations, all kinds of methods and constructors are mocked in a purely declarative way, with partial mocking specified through regular expressions in the @Mocked annotation or by simply “un-mocking” the members with no recorded expectations; that is, the developer simply declares some shared “mock fields” for the test class, or some “local mock fields” and/or “mock parameters” for individual test methods (and in this last case the @Mocked annotation often won’t be needed).
- The mechanism used by JMockit (runtime instrumentation through a “Java agent”) is simpler and safer, although it does require passing a “-javaagent” parameter to the JVM when developing on JDK 1.5; on JDK 1.6+ (which can always be used for development, even if deploying on an older version) there is no such requirement, since JMockit can transparently load the Java agent on demand by using the Attach API.
- Supports both behavior and state based testing
Refer this project on how to do things using JMockit
Benefits
- Less time spent on writing test cases
- More Coverage achieved
- Bullet proof production code
- New features can be added easily
Jenkins Runner
Get the Runner here
Analyzing Source Code with SonarQube
SonarQube Up and Running
SonarQube 3.6.3 + Maven 2.0.11 + PostgreSQL
PostgreSQL Setup
STEP 1: Make sure postgres binaries are available in your PATH.
STEP 2: Initialize postgres db, execute the following command
initdb -D datapath
STEP 3: Start the database, execute the following command
pg_ctl start -l “E:\logs\postgres\sonar.log” -D “E:\data\postgres\sonar”
STEP 4: Verify that postgres is listening on the default port (5432)
netstat -aon | findstr 127.0.0.1:5432
STEP 5: Set up the sonar database
Create user postgres, and database sonar, by executing the following command
createuser -s -r postgres
createdb sonar
connect to sonar databaseas, by executing the following command
psql sonar
Create user sonar and grant all the permissions, as sonar will create tables/indexes/constraints for you, by executing the following command
create user sonar with password ‘sonar’;
grant all on database sonar to sonar;
Download SonarQube
Download SonarQube 3.6.3, Version 3.6.3 is compatible with Maven 2.0.11
Configure SonarQube
STEP 1: disable the default H2 database by commenting the line number 48 of SONAR_HOME/conf/sonar.properties
STEP 2: Enable postgres database by un commenting the line number 86 of SONAR_HOME/conf/sonar.properties
Start SonarQube
Goto SONAR_HOME/bin, and based on the OS, go to the corresponding subdirectory, in my case it is windows-x86-64, so the full path would be SONAR_HOME/bin/ windows-x86-64
Double click on StartSonar.bat
First time you would see lots of output, as it will create tables/indexes/constraints etc.
and finally you will see something like this, as you can see that the application has started on port 9000
If you list out all tables in the current database, by executing \dt command in psql, you will get something like this
Point your browser to http://localhost:9000/
SonarQube is up and running now.
Why SonarQube
|
Since software development has started, there has been a chaos and people always ask “Is it done right?“, and we get a mix of answers
How do we evaluate the quality of the code and the developer who has written the code? It is easy enough to evaluate factory worker ( what is produced with acceptable quality), lawyer (cases won) etc. Well it can be answered if we can measure software quality. Software quality can be defined easily through abstractions, examining it from different perspectives and rating it along different dimensions Let’s put ourselves into a test, let’s see if we can read this. I cdnuolt blveiee taht I cluod aculaclty uesdnatnrd waht I was rdgnieg. The phaonmneal pweor of the hmuan mnid. It deosn’t mttaer in waht oredr the leteerrs in a wrod are, the olny iprmoatnt tihng is taht the frist and lsat ltteer be in the rghit pclae. The rset can be a taotl msess and you can sitll raed it wouthit a porbelm. Tihs is bcuseae the huamn mnid deos not raed ervey lteter by istlef, but the wrod as a wlohe. The preceding text does not contain one single word spelled correctly but proves to be readable. From a product perspective, someone could support that although the text is flawed it does the job, since it manages to remain understandable. But this has the side effect of deteriorating the final reading experience, requiring additional effort to reconstruct the words and phrases. The reader unconsciously stresses his mind in an effort to adapt and decipher the messed-up words. On the other hand, the editor assigned to improve or add to the text would have to cope with this non-standard writing practice delaying the whole process. Switch the corrupt text for a software product’s source code. The reader is now the end user of the product and the editor the developer. They both experience product quality differently, each one from their own views. The end user from a functional perspective while the developer from a structural one. Software quality measurement is a quantitative process summing up weighted attribute values, which in part describe specific software characteristics. For each characteristic, a set of such measurable attributes is defined. Now the question is, what are software characteristics? Well it could be:
How do we define the corresponding attributes?
After having the software characteristics defined, the next question which comes to our mind is how do we enforce it automatically? The answer lies in static code analysis Static Code Analysis
Static code analysis is a collection of algorithms and techniques used to analyze source code in order to automatically find potential errors or poor coding practices. The idea is similar in spirit to compiler warnings (which can be useful for finding coding errors) but to take that idea a step further and find bugs that are traditionally found using run-time debugging techniques such as testing. Static code analysis, also commonly called “white-box” testing, looks at applications in non-runtime environment. It is the only proven method to cover the entire code base and identify all the vulnerable patterns. Static code analysis is also considered as a way to automate code review process. The tasks solved by static code analysis software can be divided into 3 categories:
There are many static analysis tools available. However, Checkstyle, PMD, and FindBugs are well known and used in most of the projects Checkstyle
Checkstyle is an open source tool that can help enforce coding standards and best practices, with a particular focus on coding conventions. Although Checkstyle does cover some static code analysis features (In much the same way as PMD and Findbug), however we will mainly concentrate on Detecting and Enforcing Coding Conventions with Checkstyle. Main Focus : ConventionsPMD
PMD is a static code analysis tool, capable of automatically detecting a wide range of potential defects and unsafe or non optimized code (bad practices). Whereas other tools, such as Checkstyle, can verify that coding conventions and standards are respected, PMD focuses more on preemptive defect detection (ensure good practices are followed). It comes with a rich and highly configurable set of rules, and you can easily configure which particular rules should be used for a given project. The bad practices type consists of well known behaviors that almost systematically lead to difficulties over time. Here are a few examples of bad practices:
Main Focus : Bad practices
Findbug
Findbug is another static analysis tool for Java, similar in some ways to Checkstyle and PMD, but with a quite different focus. Findbug is not concerned by formatting or coding standards and only marginally interested in best practices: in fact, it concentrates on detecting potential bugs and performance issues. It does a very good job of finding these, and can detect many types of common, hard-to-find bugs. Indeed, Findbug is capable of detecting quite a different set of issues than PMD or Checkstyle with a relatively high degree of precision. As such, it can be a useful addition to your static analysis toolbox. Main Focus : Potential Bugs
HP Fortify
As per the HP Fortify website, HP Fortify Static Code Analyzer helps verify that your software is trustworthy, reduce costs, increase productivity and implement secure coding best practices …… Key features
Main Focus : Security VulnerabilitiesSonar
Sonar collects and analyzes source code, measuring quality and providing reports for your projects. It combines static and dynamic analysis tools and enables quality to be measured continuously over time. Everything that affects our code base, from minor styling details to critical design errors, is inspected and evaluated by Sonar thereby enabling developers to access and track code analysis data ranging from styling errors, potential bugs, and code defects to design inefficiencies, code duplication, lack of test coverage, and excess complexity. The Sonar platform analyzes source code from different aspects and hence it drills down to your code layer by layer, moving from module level down to class level. At each level Sonar produces metric values and statistics, revealing problematic areas in the source that require inspection or improvement. Main Focus : Each dimension from different perspective utilizing Checkstyle, PMD, Findbug, Fortify and many other static/dynamic code analysis tools
Why SonarQubeYou may wonder if sonarQube uses existing proven tools then why use it at all? You can just configure these tools as a plugin in the CI server and bang we will be done. Well not necessarily, well there are lots of caveats.
Features :
What makes Sonar really stand out is that it not only provides metrics and statistics about your code but translates these nondescript values to real business values such as risk and technical debt. Sonar not only addresses to core developers and programmers but to project managers and even higher managerial levels as well, due to the management aspect it offers. This concept is strengthened more by Sonar’s enhanced reporting capabilities and multiple views addressing source code from different perspectives. From a managerial perspective, transparent and continuous access on historical data enables the manager to ask the right questions. Note: Sonar is no way competing with any of the above Static analysis tools rather it complements and works very (really very) close with these tools. In fact it seizes to work if these static analysis tools (Checkstyle, PMD and Findbug) does not exists. Further we can integrate Fortify with Sonar using this plugin References
|
Craftsman Nadeem 