Yesterday, I was helping a coworker understand part of an application I had worked on previously. When we had finished going through his issue, he asked whether he needed to write unit test. Obviously, I recommended that he write new unit tests and ensure the old unit tests did not break. He then asked me how he should do that. This is where my assumptions caused a problem.
I tend to develop software using an IDE with various supporting tools and scripts. I assumed he also had a similarly working environment. However, he did not. Our company does not require the use of a specific IDE or toolset, which has its good side and bad side. The good side is that some people can use an IDE like Eclipse, IntelliJ or NetBeans. The bad side is that some people continue to use TextPad. For an application of significant size, a text editor is a painfully slow way to write code. So, I offered my coworker what I thought would be a good development environment based on what our company typically uses. Now, each person and company will need a different setup based on what you need to support, but some things are fairly standard. Following are some good tools that need to be part of your personal development environment, with a significant bias towards java development.
Integrated Development Environment (IDE) – An IDE is critical to your productivity regardless of your programming language of choice. If you say that you are fine with a text editor and a bunch of batch files or shell scripts, then I will argue that you have created your own IDE just in a minimalist sort of way. For java development, there are 3 major IDEs, Eclipse, IntelliJ and NetBeans. Sometimes I find it shocking that we need to talk about the benefits, but some people may need to be reminded. You get incremental compiling, search features, code completion, quick navigation and many refactoring options. With many of the tools in this list, there is likely some way to integrate it with your IDE as well.
Automated Builds – For the individual developer, you still need to have a simple way to generate a build. Ant and Maven are two of the popular choices. They both have plenty of community support and various plugins for other tools. Both allow you to create custom plugins as well, so that you are never really limited to what tools can be integrated. If you use Eclipse, you can also integrate your build scripts so that you never have to leave the IDE.
Automated Unit Testing – If you read this blog consistently, you have seen a few testing posts lately. Unit tests really are a fantastic security blanket. If someone new modifies code, you can quickly tell if something is broken or whether the tests need to be changed to reflect the new requirements. JUnit and TestNG are popular frameworks in the Java space, and there are frameworks for almost any language. I use JUnit because that is what I started with ages ago, and it has a good Eclipse plugin. I can quickly write a test in Eclipse, and click “Run As -> JUnit Test”. If I see a green bar, I am a happy man 🙂 You can include all of your tests in your automated build to ensure that everything works well together. JUnit provides a way to generate HTML reports which display a summary of the entire project, each package and each class.
Test Coverage – You could have a ton of unit tests, but how do you know if you really are testing your code well enough? Test Coverage tools like Clover and Coberatura help you understand what lines of code are left untested. Sometimes the percentage numbers may seem a little off, but the idea is that you need to know if you have left something untested. My understanding is that you want to achieve over 90% test coverage, and hopefully about 95%. That last 5% is typically going to be exception cases that you hope never happen anyway. There are some Eclipse plugins for test coverage tools, but I am not a big fan as they feel like they get in the way. Cobertura does output some nice html reports, in the same style as the JUnit html reports.
Shell Scripts – I know I said earlier that you should use an IDE instead of a text editor and shell scripts, but sometimes there is just some minor task that needs to be done. The shell can also be used to automate things that do not have a plugin in your IDE. For Windows users, there are normal batch files, or you go for more unix flavor with Cygwin. For Linux and Mac users, you have the pleasure of a real unix shell at your disposal.
Deployment Server – If you are doing some sort of web development or server development, you need to be able to deploy your code quickly and easily. For web development, this typically means that you have installed your application server, e.g. Tomcat. More importantly, you want to make sure that you do not have to click 18 different links on some administrative console in order to deploy a new build. You could automate this using a shell script or your application server could have a plugin for your IDE. Whatever helps you deploy faster is a good thing.
There are likely a bunch of other tools that you could add to boost your producitivty, but this is the short list. One item that I would love to add, but is not always possible is your database server. In corporate environments, this is typically very difficult to get approved, but there is no harm in asking.
Are there tools that are indispensible to you that are not on this list?
9 thoughts on “What Does Your Development Environment Look Like?”
Most of my development lately has been web app development in PHP, I just use Coda for OSX.
Everything else I use just about everything else, whatever happens to suit my fancy…Eclipse, Visual Studio, and occasionally the good ol’ notepad.
JUnit/NUnit alone is not enough for unit-testing; you also need an isolation (mocking) framework, e.g. NMock, Moq, etc.
It would be nice to mention .NET equivalents of Java tools, e.g. NAnt, NCover, etc.
Also very helpful are efficient (better than Notepad.exe) text editors for quick edits of some data or configuration files. I like Notepad++, it has syntax highlighting for a number of languages, including XML.
Finally, what about viewing/searching giant log files? I like FAR Commander’s built-in viewer/editor.
There is never a reason to use Notepad 🙂 I tend to use vi/vim for text editing as I have gotten used to it over the years.
I did not want to get too deep on some of the items because the post is already long enough. As you said, you typically need a mocking framework, and probably a good testing/database tool like dbunit.
Regarding the .NET side of things, I will avoid that whenever possible as I am not a .NET developer. I do try to mention that most of these tools have equivalents in other languages, we just need to find them.
For “large log files”, I do not have a tool of choice, so I will need to look at FAR Commander. I tend to feel that on the development side you logs should never be that large, or you are just logging too much information. On the production side, you probably do need something.
Here are the tools I can’t seem to get through the day without booting up at least once.
Unit Testing: JUnit and DOH
Test Coverage: EMMA
Shell Scripts: Python
Deployment Server: Tomcat
Other tools I use frequently are Notepad++ and XML Spy.
I have not used Emma enough to comment, though their Eclipse plugin isn’t that bad. Scripting languages are totally a matter of personal preference, so I won’t comment unless I want to start yet another religious war 😉
I have not heard of DOH. I will have to take a look.
Interesting article, I myself found Netbeans and downloaded just for kicks. Only to dabble in it and see the raw power that comes with Netbeans IDE.
I prefer three programs for development right now, Notepad++, Codeblocks for C++, and Netbeans for general purpose stuff. Notepad is great for handwriting and learning code, but it was never meant to deploy large applications. For a beginner learning a language or something, it’s just dandy.
[…] What Does Your Development Environment Look Like? (regulargeek.com) […]
I’m a *huge* fan of a tabbed console app. (See: http://www.darose.net/konsole.png) In fact, I pretty much can’t function without one. The thought of trying to search through a dozen separate console windows to find the one I’m looking for makes me shudder! 🙂
In the same spirit, GNU screen is also “can’t do without app” for me, as it allows you to set up the equivalent of a multi-tab console when you’re accessing a remote box (via ssh) from the command line.
2 huge productivity tools!
Comments are closed.