I found myself needing to run Selenium tests from Java against a Selenium server running on a port other than the default 4444. Every example on the web showed me almost the right way to configure this from within JUnit... so now that I've got it working, I'm documenting it. :)
public void setUp() throws Exception {
// this is the normal way
// setUp(server_url, "*chrome");
// this is the alternate port way
selenium = new DefaultSelenium("localhost", 11111, "*firefox", server_url );
selenium.start();
}
Hopefully this will save a few others some time!
Free Bonus Tip
Here's how to start and stop the Selenium server from an Ant script.
<target name="start_server" description="Starts a Selenium Server in the background">
<java jar="${lib}/selenium-server.jar" fork="true" spawn="true"/>
</target>
<target name="stop_server" description="Stops your local Selenium Server">
<get taskname="selenium-shutdown"
src="http://localhost:4444/selenium-server/driver/?cmd=shutDown"
dest="result.txt"
ignoreerrors="true" />
</target>
Update
The above Ant script worked for me on Linux, but seems to not work on Windows. (sigh).
Change the arg from value= to line= and it's now working on Windows.
<java jar="${lib}/selenium-server.jar" fork="true" spawn="true" >
<arg line="-port 4444"/>
</java>
I've also found this useful.
<waitfor maxwait="30" maxwaitunit="second">
<socket server="localhost" port="${selenium.server.port}"/>
</waitfor>
Cobertura has an Eclipse plugin, but it's suffering from neglect. So I'm putting a small bounty on it. $250 to the person who gets it back up and running.
My requirements for the plugin?
-Runs Cobertura from within Eclipse
-Highlights your tested and untested source code
-It'd have to run to one of the core committer's satisfaction. When they're happy, I'll mail you a check. It's not a ton of money, but it's a few dollars.
There you go... there's a file in the build (eclipse-plugin.zip) that'd make a fine starting point.
Given that so many people at are Java One this week, it might be a bad time to announce this... on the other hand, with so many people busy, it might be ~your~ chance to get a head start. :)
And Java 6 arrives with a bit of controversy.
Ted rants about the lack of a 32 bit version in Why, Apple, Why?
In a nutshell, if your Mac has a Core Duo CPU, you're running 32 bit. You must have a Core Duo 2. (see this Wikipedia entry). Oh, you must have Leopard (10.5.2) as well.
Here's a great post that shows you how to make 1.6 your default Java. The Apple installer doesn't do that... apparently they don't trust the version enough to be the default Java on your box. Not inspiring confidence with that decision...
Man, I really love Ruby.
Jeff Brown is a great speaker and we're lucky to have him coming in locally. If you're tinkering with Groovy or Grails, or thinking about it, I strongly encourage you to come out tonight and pick Jeff's brain.
In addition, since this is a NFJS sponsored trip, a free pass to the Research Triangle Software Symposium will be raffled off.
You'll find more info about the meeting and directions at The Triangle Java User's Group web site.
I'm often asked what static code tools I like for Java. First, I've been nearly full-time in Ruby and Rails for a year now, so I may be out of date, but here's what I like.
Findbugs
Findbugs is the absolute best tool for static code analysis. But best is a nebulous and somewhat relative term. I prefer something with a very low noise to signal ratio, and Findbugs has that. Other tools (like PMD, see below) report a lot more information. So much in fact that real issues can get lost in the clutter.
Here's a quote for you... I've never run Findbugs on a production codebase and not found at least one legitimate bug. A real, not theoretical, issue.
Findbugs is free (open source even!) and the rule set can be edited with an XML file. They have an online (Java Web Start) version, Eclipse plugins, and more. It's an all around a great tool.
PMD
I don't like PMD as much because it has so much information in the reports. The good tends to lost in the false hits. However, after you've gotten your product in good enough shape that Findbugs runs cleanly, then PMD is your next step. You'll have to work a bit harder to find the good results, but it's worth the effort.
CPD
A real gem in the PMD toolbox is the invaluable Copy/Paste Detector (CPD). This tool will scan your entire codebase and point out every place where someone has lifted a bit of code.
The problem with the copied code is when you fix a bug in one spot, the fix is rarely copied around to all the pasted code. When you spot duplicate code with CPD, take a long hard look and see if you can't pull that code into a utility class. This won't catch everything that violates the DRY principal, but it's a good start.
UPDATE:
Tom Copeland sent me some extra CPD information. CPD also has a web-based launcher here so you can try out CPD without having to install the entire PMD suite. He also mentioned the PMD Applied book and said that chapter 5 goes into great detail on CPD.
Thanks Tom!
Code Coverage
You should be running a good code coverage tool to see what code your automated tests hit (or your manual tests for that matter). There are several great tools available, but I'm partial to Cobertura. It's a solid tool with great, easy to read reports. There are several other great tools available (Emma and Clover come to mind).
I'm not religious about my code coverage numbers... I don't think you need to set a code coverage number and make it a goal. I'm more concerned with using code coverage as a guide to direct my efforts.
Another tool inside Cobertura that you can use to direct those efforts is the Cyclomatic Complexity number. I've found it to have a direct correlation to code with bugs. The more complicated the code is, the more likely it is to have problems.
Continuous Integration
How often and from where should you be running these tools? Every time you touch the code of course. You don't want out of date reports do you? :)
Read Martin Fowler's classic article Continuous Integration, then go download the binary release of Cruise Control. The latest release has a nice Dashboard (see Jeffery Fredick's blog entry about the 2.7 release.)
I like to roll my static code tools into an Ant task and then run them from within Cruise Control. I publish the reports as part of the project's artifacts. This ensures things are always up to date, as well as providing a historical reference point I can revisit.
There are other popular CI tools available to you as well. These days Bamboo and Hudson are becoming more popular. This CI product matrix is a little out date, but a good starting point if you want the lay of the land.
Agitar
I've pointed you at a lot of open source tools... let me point you at one really big commercial offering. Agitar covers most of what I've listed above, and a lot more, including automated test generation. (Never let those automated tests replace a culture of great hand-crafted tests... use them to supplement, not replace.) Some companies just feel the need to have a commercial product in place. If you work there, check out the Agitar suite.
How Much?
If you put too many analysis tools and reports on a single page, developers tend to ignore them all. Pick one or two at first. This blog entry is a nice write up of one of my favorite strategies.
I hope this gives you a few options to check out. Just be sure not to overload the "customer" with too much information at one time. Start small and branch out.
Enjoy!
ps. Did I miss a tool or category? Drop me a line!
Jason Rudolph is presenting his popular talk on Getting Started with Grails tonight at the RTP Java User's Group. If you're wanting to learn more about this dynamic language innovation on the Java platform, don't miss this event.
Even if you don't use Grails at your day job today, you need to understand the basic concepts. Then you'll be able to intelligently evaluate other frameworks when they come across your desk tomorrow.
