This post was originally published in my blog smartpuffin.com.
Let's imagine we just wrote a method calculating distance between two points on ...
For further actions, you may consider blocking this person and/or reporting abuse
This is a really good tutorial, but there was an early line that almost made me stop reading. If you were to change, "Let's imagine we just wrote a method...," to "Let's imagine we're about to write a method...," and adjusted the content accordingly, then you could change the title to "Writing Great Unit Tests" instead of just good ones.
Hi Benjamin,
I think you're hinting at TDD.
In real life, you usually solve a problem, not simply write a piece of code. Unlless you have an amazingly detailed spec, the interface is usually unknown, and you cannot write tests for it at this stage. Usually, it takes some time before the interface is finalised. Thus, tests have to be postponed for a bit.
Second reason I didn't mention it here is because following TDD is rather difficult, especially for beginners. I don't want to scare developers off unit testing because they would think it is too difficult. It is actually easy - if you are starting slowly, with simple ways to do it.
Thirdly, I don't mind which way you come to the final result. If the final result is code sufficiently (sic!) covered with tests, I don't mind if you wrote tests before or during or after. One absolutely can write a great unit test suite without following TDD religiously. Gatekeeping of this sort - "you're not a good developer if you don't follow TDD" - has never seemed a good idea to me.
I usually advise to write tests along with the code, if possible, but I don't make it mandatory.
I don't mind, of course, if people do follow TDD. If it works for you, great! If you prefer it, why don't you write an article explaining its benefits?
Why is longitude and latitude splitted into two variables? When you want calculate distance in 3D, you will write a new method?
This is mainly to make the example simpler.
Usually, you have an option to accept latitude and longitude as separate variables, or to accept a
Point{double latitude, double longitude}instance. My preference would be to use the Point, but then I would have to introduce an extra piece of code, and this is a unit testing tutorial, after all.However, in real life I once opted for using doubles :). In that project, we were using two different libraries, and they both had Point classes - but different ones, not related to each other :-D. (And the language wasn't C++ or a similar one with a powerful template system.)
Regarding the distance in 3D, this is an interesting and difficult question. Of course, it depends on the domain area, if you want to do this at all. In many applications, this is not needed. If you had to calculate the distance on our planet with elevation, then the simple difference in elevation won't do - you would have to calculate the surface distance (not going through the mountain, but going over it, for example). Then you would have to use a much more complex formulas (and I have never done that), or calculate distance by roads (I have done that, but then it becomes a graph problem, and the total elevation change should be counted in the time spent driving, or something like that).
But then again, this is a unit testing tutorial, and for this purpose, I use a round planet with no elevation :).
OK, thanks.