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.
Taming of the Subversion, a SVN primer; part 2
In part one I went over how to get SVN setup and configured on your system. In Part two I will get into the day to day activities of using SVN. In this part of my SVN primer I will cover; Checking out, committing, updating, synchronizing, branchings, and tagging. I will also go over some terminology to help make things a little more clear. I will be using subclipse as my SVN client in this part of the primer. I find using SVN from within an IDE to be more natural and including directions for both subclipse and tortoiseSVN to be confusing and there is very little difference between the two anyways.
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.
8 tips for new programmers
A successor in spirt to my 7 tips for every person wishing to be a programmer, here are 8 tips for when you finally land your first development job. These tips will hopefully help prepare you for your new job, or help get you up to speed with the rest of your team.
1.You don't know anything – So you finally have your degree and after four years of intensive studying you think you know everything there is to know about programming. Like every other developer you will soon learn (or already have) that you know nothing. Be humble, put in your hard work, and know that over time you will learn.
Categories
Tag Cloud
Archives
- November 2009 (3)
- October 2009 (18)
- September 2009 (15)