Mocking JDBC Connections with MockRunner
Last week I published an article, An Intro into Test Driven Development with Junit4, which got somewhat mixed reviews. One particular commenter on reddit suggested I didn't understand that unit tests shouldn't talk to its data source. I decided to do some investigating into his claims, you can check out my findings here. I was however intrigued none the less and started looking for a tool that would allow me to easily mock a JDBC connection. I found Mockrunner to be the easiest to use of the ones I have found. Below is a brief tutorial on how to use Mockrunner. (Keep in mind that I am still fairly new to using Mockrunner)
Ramblings: Should unit tests talk to a data source?
Last week I published an article on test driven development. One person who read my article (briefly) suggested I did not know that unit tests shouldn't talk to their data source. I plan on covering how to mock JDBC connections later this week, however I wanted to do some research to see if what my critic says is an industry standard or a philosophical choice.
Surprisingly there seems to be relatively little information on this subject, or I have been incapable of finding information. From what I have gathered though, the theory that data sources should be mocked is sound, but its may not always be practical to implement it. Below is two reasons why data source connections should be mocked and three reasons why they should not.
Link dump 11/3
http://www.developerart.com – A new blog like my own. While not a whole lot yet, the content that is on his site is of high quality.
Kind of a smallish link dump I know. I plan on getting some new articles posted this week, namely an update to my TDD article I posted last Monday. So check back soon.
An Intro into Test Driven Development with JUnit4
Please read the technical guide before starting this tutorial.
This article will mark the first of a long-term series covering professional software development. For the lowdown on this project check out this article. Be sure to give me your feedback as it will be vital in helping me develop better tutorials in the future.
Test driven development seemed like a natural choice as a lead off to my series of tutorials as I had to explain why I am writing all these tests. It is also a very good development methodology that will actually save a lot of time by reducing the amount of time spent debugging. For this tutorial and the entire project, I will be using Junit4. For a synopsis on test driven development you can check out the wikipedia article here. If you need a brief refresher on JUnit you can read my tutorial here (written in Junit3).
Comments are a sign of bad code and I am not sorry for saying it
In my recent article, 8 signs your code sucks, one of my signs of bad code is: “You need to use comments to explain the code.” I have since taken a lot of flak for suggesting this and I want to clarify my point and why I am not backing down.
Not javadoc - I am NOT referring to Javadoc or its equivalents in other languages. I absolutely do agree that a method or class should have accompanying documentation at its declaration stating its purpose and its inputs and/or outputs.
8 Signs your code sucks
As a wide eyed junior developer when I first began working on large projects I simply accepted that it is difficult to fix bugs or find where an action is being executed. If only I knew then what I know now, I would had saved myself hours of frustration. The first step to writing good code is accepting the code you write (or work on) is crap, but sometimes you need to know what to look for. Here are some signs that your code sucks.
A method is larger than the screen – A method should only perform one specific task. A method should not contain the logic code to determine if the username field contains data, is valid, and that user exists. If a method is too large to fit within a single screen, that is a (very) good sign it is doing too much.
12 Tips to make you more productive using Eclipse
Integrated development environments make developing application fair easier. They highlight syntax, let you know if you have a compilation error, and allow you to step through your code among so many other things. Like all IDEs Eclipse has a bunch of little shortcuts and tools that can make your life a lot easier, I've compiled a list of several that I use on a daily basis:
1. Auto-complete – Eclipse has an auto-complete feature that can be accessed with ctrl + space. When clicked a small pop-up box is displayed with a list of context sensitive suggestions. If there is only one possibility then Eclipse completes it for you.
Link Dump 10/13
http://www.codeigniter.com – An excellent and lightweight framework for developing PHP applications
http://sites.google.com/site/yacoset/ - I may not agree with everything the author says and frankly he probably doesn't care. But there is plenty of good information on his site none the less.
http://solitarygeek.com/ - If you like my site then you will probably love this one. Similar in writing style and purpose, just a more mature blog written by a more experienced developer.
Null Pointers; tips for day to day development 10/9
Similar to link dumps, as I come across tips and ideas, that alone may not justify a blog post, but I think may be useful, I will bundle them into these posts. Some of these tips may be obvious, others esoteric, and some representing my personal preference, but I think there should be something in here for everybody. Let me know if you have any others you want me to add.
Link Dump 10/6
http://sourcemaking.com/ - Co-authored by Martin Fowler, a bunch of useful information and best practices on this site.
http://www.pbell.com/index.cfm/design-patterns -A wealth of information covering many different areas of programming. Definitely something here for everybody.
http://marxsoftware.blogspot.com/ - A well established blog with hundreds of articles covering mostly Java.
Categories
Tag Cloud
Archives
- November 2009 (3)
- October 2009 (18)
- September 2009 (15)