• Home
  • Events
  • About
  • The Best Groovy Inspections You're Not Using

    January 18th, 2012

    Many, many tools perform static analysis on code. There are all sorts of automated ways to look through your code and tell you if there are likely errors or not. FindBugs, PMD, and CheckStyle are some of the big names from the Java world. On the Groovy side we have two real options: IntelliJ IDEA and CodeNarc.

    This post highlights my favorite static analysis rules for Groovy in IDEA that are not enabled by default. Groovy in IDEA 11 has well over 100 rules, but less than half of them are activated when you install the product. To turn these rules on you’ll need to go into Settings (Ctrl+Alt+S) and enable them under Inspections.

    So here are my favorites that I think you should turn on:

    Threading
    Threading comes first because these inspections have saved my butt in the past. None of them are enabled by default, so do yourself a favor and enable a few. These ones are all must haves:

    * Access to static field locked on instance data – Reading and writing a static field from multiple threads is not thread-safe. It needs to be done within a synchronized block. Do you know what happens when you synchronize on instance data, like this:

    The object ‘lock’ is an instance field, not a static field. So this assignment within the synchronized block is not thread-safe. It is possible that the static field is accessed from multiple threads, which can lead to unspecified side effects.

    * Synchronization on non-final field – If you are accessing a variable within a synchronized block then your synchronization token must be final. Consider this code:

    The field ‘lock’ is not final, so different instances of MyClass may have different values for lock. The result is that different threads may be locking on different objects even when operating on the same object. Make your locks final.

    * Synchronization on variable initialized with literal – Do you understand the problem with synchronizing on a primitive literal? Consider this code:

    Strings are interned by the JVM, so the string ‘my lock’ may also be used by another class. Numbers are even worse because they can be assigned from a cache. Some other object in the system may be initialized with the same literal, and could create an accidental (or malicious) dead-lock situations.

    * Unsynchronized method overrides synchronized method – In some limited circumstances you may actually want to override a synchronized method with an unsynchronized one. But probably not. More than likely you don’t even know and you are accidentally creating a subtle bug. If the parent is synchronized then the child should be also. Or better yet, make the parent final.

    Probably bugs
    * Named arguments of constructor call – This inspection warns you when something like the following happens when using named arguments, which is almost certainly a bug:

    See the problem? The field is named ‘orderId’ with a big ‘I’ and the constructor call uses ‘orderid’ with a small ‘i’. RuntimeException if you run this code. This is a type of bug that CodeNarc cannot find because the type information of the classes is so limited. IDEA keeps track of types much better and can do nice things like this.

    * Access to unresolved expression – There has been a lot of talk over the years about adding static compilation to Groovy. Some people want to be warned by the compiler or in the IDE if their Groovy code is referencing an object that does not exist. For example, they’d like this to produce a warning or error:

    See the problem? The closure parameter is named ‘parm’ but the closure references the parameter by the standard name ‘it’. The access to unresolved expression inspection turns this into a warning or error in the IDE. IDEA is quite smart about it too and knows all about delegate/super and the other Groovy dynamic variables. If you like this sort of thing then be sure to read up on Grumpy mode in Groovy 2, coming soon.

    Control Flow
    There are many features in Groovy that simplify standard and verbose Java code. Two of these are the Elvis operator and the Null-Safe Dereference. IDEA contains inspections to help you migrate to the new way of writing code with these features.

    * Conditional expression can be elvis – This inspection migrates you from code like this:

    And suggests you rewrite it into the equivalent Groovy:

    Is it always safe to make this transformation? (Think about it for a few seconds). GroovyTruth means it is not. Technically speaking, the two code snippets are not equivalent: value != null may be true while value is false, such as when value is an empty String. Overall, I like the inspection but you need to be careful with it.

    * Conditional expression can be conditional call – This inspection promotes the use of the Null-Safe dereference. This following code produces a violation:

    … and you will be prompted to transform it ito:

    These two code blocks really are the same and this can be safely accepted as the correct way to write the code.

    * If statement (or conditional) with identical branches – I periodically refactor code and accidentally leave an if or conditional statement with identical branches. These are of course redundant and can be cleaned up by removing the if expression. If you have good unit tests and use automated refactorings then this sort of things happens from time to time. The cleanup reminder is nice.

    Error Handling
    * Unused catch parameter – My favorite Error Handling inspection is ‘Unused catch parameter’. Consider this code:

    What happens to the stack trace in this scenario? It gets eaten up, never to appear in a log. You shouldn’t have any unused catch parameters. If you really don’t care about the exception then name it ‘ignore’ or ‘ignored’ to suppress the warning.

    Validity issues
    * Duplicate switch case – Groovy has Switch on Steroids, meaning you can put almost any object in the case statement, including regular expressions:

    See the problem? The same regex appears twice. The second case will never be executed, even if it would match. As long as your case statements have literals in them then IDEA can verify that there are no duplicates.

    Naming Conventions
    Lastly, there are a whole bunch of naming convention inspections that you can activate and configure. If you’re not using CodeNarc (why not?) then you should at least activate some of these. Standards, on a whole, are good to adhere to.

    IDEA Inspections of CodeNarc?
    So which should you use, IDEA or CodeNarc? These two tools complement each other. There is good reason to use both CodeNarc and IDEA together. CodeNarc does have more inspections than IDEA, but the IDE integration in IDEA is better. Pressing Alt+Enter typically rewrites the offending code, and the speed of the actions are much better in IDEA. Also, the static analysis rules do not overlap between the products because the CodeNarc developers (that’s Chris Mair and myself) already use IDEA and made a conscious effort not to duplicate anything.

    And if you do want to use CodeNarc and IDEA, then you might try out the CodeNarc IDEA plugin.

    If you like this then you might check out some of my other IDEA related posts: The 10 Best Inspections You’re Not Using (in Java), or the IDEA archive on my blog and the Canoo blog.

    And remember if you need Groovy and Grails help, then give us a call or drop me an email at hamlet.darcy@canoo.com

    Share and Enjoy: These icons link to social bookmarking sites where readers can share and discover new web pages.
    • email
    • Print
    • Twitter
    • LinkedIn
    • XING
    • Facebook
    • Google Bookmarks

    Android Testing in IntelliJ IDEA

    January 12th, 2012

    Google’s Android site has some fairly detailed instructions for testing Android applications… from Eclipse. They were nice enough to supply a “Testing from Other IDEs” page, but that is nothing more than instructions on using Ant and the command line. Well, if you are using IntelliJ IDEA then you already believe the IDE is going to be a better tool than Ant for this. It’s easy to set up a test project in IDEA and get your tests running. Here are some simple instructions.

    Prerequisites

    This tutorial assumes you have installed IntelliJ IDEA and an Android SDK, and also created an Android project. If you haven’t yet, then you should read Testing Fundamentals accessible from Google’s Testing Home page.

    Creating a Test Project

    Your Android tests are going to be placed in a separate module from your main Android application. Remember: an IDEA project is composed of several modules. We’re going to have the main application module and the test module. Each module has it’s own set of dependencies and classpath. (Eclipse users confused about the terminology should read this). Here are the steps to follow to set up a test project:

    1. Have your main project open in IDEA
    2. Create a new module using the menu File->New Module
    3. Select “Create module from scratch” and click Next
    4. Select “Android Module”, give the module a new name, and click Next. You should put the module in a directory called “tests” that is in your project root. That way your project will follow the same naming conventions that Ant expects, making the project easier to set up in a CI server later. Here is what your wizard screen might look like:

    Adding an Android Testing Module

    Adding an Android Testing Module

    5. On the next wizard step just click Next to create a source directory for your files.
    6. Finally, on the last wizard step select “Test” under Project properties. Make sure it is going to test your module. Then Finish.

    Select Test as Project Type

    At this point your two modules exist: the production module and your test module. If you look in the Project View (Alt+1) you will see both modules. Mine are named “android-testing-in-idea” and “tests”. You’ll even be given a template test for your main activity. It’s pretty slim so you will certainly want to write some of your own tests. IDEA isn’t smart enough to automatically create the test content for you… at least yet.

    Running Tests

    Running tests is simple. A run configuration to run all tests was created for you when you added the project. Click the ‘run triangle’ to run the tests or the ‘bug triangle’ to debug the tests. You’ll be prompted to select an emulator if you don’t have one set by default.

    run all tests

    Click to Run All Tests

    There are other ways to run tests at a more granular level, too. To run all the tests in a package, right click the package and select Run (Ctrl+Shift+F10). To run all the tests in a class, right click the class and select Run (Ctrl+Shift+F10). You can also run individual test methods one at a time. Just right click inside the test method within the IDE editor and select Run (once again, (Ctrl+Shift+F10)).

    You may want to switch the emulator version from time to time in order to test across multiple devices. You can bring up the Run Configuration from the drop down menu highlighted in the screenshot above. It opens a screen like this where you configure the run target:

    Configure the Test Run Target

    Configure the Test Run Target

    You can switch the emulator here to a different version. Be sure to check out the other tabs as well. The Emulator tab allows you to configure the network speed and latency, and the Logcat tabs lets you configure one or two things about Logcat. Handy.

    Viewing Results

    So you want to view the test results? Well results window probably popped up on screen after you ran the test. Anyway, if you’re still confused you can click the Run (Alt+4) or Debug (Alt+5) drawer and see the JUnit results. There is also a Logcat drawer to click (sorry no shortcut) to view the logs.

    Viewing Test Results

    Viewing Test Results

    Other Tools

    The last thing you need to know is a little about the other tools. You can manage your emulator ROMs using the AVD Manager. The menu option for that is Tools -> Android -> AVD Manager. Also, you can change the project compatibility to be a different version of Android OS. It’s under File->Project Structure (Ctrl+Alt+Shift+S) then click Module SDK. Finally, if you want to set the project up for continuous integration then head on back to the Ant command line guide from Google. It’s best not to have the IDEA project file drive your builds.

    You made it to the end. Thanks for reading! And remember, Canoo is here to help with your Android and Mobile needs. Email me directly (hamlet.darcy@canoo.com) or give us a phone call. Thanks.

    Share and Enjoy: These icons link to social bookmarking sites where readers can share and discover new web pages.
    • email
    • Print
    • Twitter
    • LinkedIn
    • XING
    • Facebook
    • Google Bookmarks

    css.php