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).
The start of a long journey
A couple of weeks ago I posted about my ideas for the future of this site. Well today I start making good on those lofty promises. I will be posting my first tutorial, which will cover test driven development, shortly. Before I do that I want to give a bit of an explanation of this project, why I am doing it, what I hope to accomplish, a few other thoughts, and finally some technical notes.
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.
Thanks for the hits!
My blog passed a major milestone today, I finally eclipsed 1,000 visitors in a single day! I want to say thanks to everybody who has visited this site and I hope you find it useful. I have a lot of big ideas for the future so be sure to check back again sometime. Help support Turnleaf Design by leaving comments, or sharing posts with friends, colleague, or on social sites. Thanks again!
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.
Taming of the Subversion, a SVN primer; part 3
In the third and final part to my SVN primer I will finish up with my day to day tasks and I will go over how to add SVN properties to your project. The first two parts can be found here: 1, 2.
Categories
Tag Cloud
Archives
- November 2009 (3)
- October 2009 (18)
- September 2009 (15)