When I talked to Michael Feathers about why constraints are good, he also mentioned an example of where he thought things were going wrong.
Some people who use test-driven development, also use tools that allow the to peek into classes and read private variables. That is an efficient way to ensure that some method altered the [...]
This is the third installment in my series on sensible exception handling and will cover when and how to catch exceptions.
To quickly summarize, the series looks as follows:
Throwing Exceptions Using Assertions Catching Exceptions (this one) Logging Exceptions
The information in this post is divided [...]
This is the second part in a series of four on exception handling and it focuses on an area related to exceptions — assertions.
A quick summary of posts in this series:
Throwing Exceptions Using Assertions (this one) Catching Exceptions Logging Exceptions
Guidelines for assertions
An assertion [...]
This is the first post in a series of four on exception handling. The series will cover what I think is a good and sound strategy for handling exceptions and errors in your application. It is written with Java in mind, but is applicable to most languages which feature exceptions. This first issue will go through the art of throwing exceptions.
This is a bit of a rant, but I just gotta get it out of my system.
I’m getting frustrated by people I talk to who seem to misunderstand the whole point of agile software development (IMHO).
Different ways of reducing risk
The point with agile, as far as I understand, is to reduce risk and thereby costs [...]
Sometimes a constructor doesn’t communicate intention very effectively. This could be because instantiating the class in question isn’t as straight-forward as “creating a new object”, or because there are many alternative constructors. In those circumstances it might be useful to use well-named static or non-static methods to create instances of the class instead.
I want to describe a situation I came across where designing for testability seems to be in conflict with the always-valuable principle of loose coupling.
I’m constantly trying to become better at estimating how long a development task will take. As one step in this process I decided to create a simple web-based timer which I could use to measure time. Shouldn’t be too hard, I just needed a simple stop watch — the simplest thing that that could possibly work. That’s what I thought at least.
While evolving a design is good and nice one has to remember that even though big design up front might not be a good idea, all the hard design work still needs to be done at some point. Otherwise you’ll just end up with a big piece of garbage. Therefore, while starting with a story, do take time and think it through and answer a couple of the following questions for yourself.
I just wanted to describe what for me became an “eye-opener” regarding Test-Driven Development; that when you remove duplication, you should look for not only duplication of logic, but also duplication of data.