|
»
« Return to Thread: Are you really using JUnit during your development?
Re: Re: Test-friendly, but not caller-friendly?
by Michael Feathers
::
Rate this Message:
Elliotte Harold wrote:
>Michael Feathers wrote:
>
>
>
>>Frankly, I wouldn't want to have only #5 at the API level, but I think
>>that this tendency we have to believe that we can not have an agreement
>>with users that is not enforced by code leads to a great deal of
>>trouble. Particularly in the area of visibility.. many developers assume
>>that no written agreement can be sufficient if something is made
>>public. I think that the issue is that we are not used to thinking
>>about agreements beyond the code and we're not used to holding people to
>>them.
>>
>>
>
>I'd rephrase that a little. We have decades of experience with
>documenting software and APIs and trying to make decrees (not agreements
>as I'll explain in another post) about how it must be used. Experience
>has proven that this doesn't work well. Consider the issues with even a
>very well-known code base like Java with very well known and documented
>design principles. How many mucked up hashCode()-equals()
>implementations do we still encounter? Ten years ago, it was even worse.
> And don't get me started on runtime vs. checked exceptions. Even major
>APIs pushed through the JCP still get this exactly backwards. You need
>documentation, certainly, but documentation alone is not sufficient for
>robust code.
>
>I'd argue that by and large, Java has been very successful. It provided
enough hand holding to allow average programmers to deliver a wide array
of good applications.
When they designed Java, they knew that they were targetting the middle
of the road... they left out a slew of features which would have made
life easier for more advanced developers and they did it deliberately to
make the language more approachable. Despite that, there are people who
still screw up and they screw up precisely because the language offers
enough freedom to screw up. On balance, that's okay because if it
didn't it would probably be far less functional than it is.
A lot of the backlash that we are seeing against Java right now comes
from the fact that many people are discovering that they can be more
productive without the hand holding, and they are willing to assume
responsibility to leave it behind.
>By contrast, things that we can enforce in code do seem to work pretty
>well. That we also have decades of experience telling us. Garbage
>collection improves on manual memory management. Checked exceptions get
>programmers to write a lot more error handling code than documentation
>ever did. (Not quite as much as they should, of course, but a lot more
>than they used to.) Automated unit tests (ideally run without programmer
>involvement on a continuous integration server) keep programmers from
>breaking the build. Having the source code repository either verify
>formatting or reformat code before checking it in keeps badly formatted
>code from being checked into the source code repository.
>
>These aren't absolutes. They are matters of degree. But they are large
>matters of degree. We know these things. We've learned them through
>experience. Rules we enforce in code and systems are far more likely to
>be followed than rules we merely document.
>
>True, but it is a double edged sword. It works when people don't need
the freedom to deal with exceptional cases, or when they do need the
freedom and have it.
Michael Feathers
www.objectmentor.com
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/junit/
<*> To unsubscribe from this group, send an email to:
junit-unsubscribe@...
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
>Michael Feathers wrote:
>
>
>
>>Frankly, I wouldn't want to have only #5 at the API level, but I think
>>that this tendency we have to believe that we can not have an agreement
>>with users that is not enforced by code leads to a great deal of
>>trouble. Particularly in the area of visibility.. many developers assume
>>that no written agreement can be sufficient if something is made
>>public. I think that the issue is that we are not used to thinking
>>about agreements beyond the code and we're not used to holding people to
>>them.
>>
>>
>
>I'd rephrase that a little. We have decades of experience with
>documenting software and APIs and trying to make decrees (not agreements
>as I'll explain in another post) about how it must be used. Experience
>has proven that this doesn't work well. Consider the issues with even a
>very well-known code base like Java with very well known and documented
>design principles. How many mucked up hashCode()-equals()
>implementations do we still encounter? Ten years ago, it was even worse.
> And don't get me started on runtime vs. checked exceptions. Even major
>APIs pushed through the JCP still get this exactly backwards. You need
>documentation, certainly, but documentation alone is not sufficient for
>robust code.
>
>
enough hand holding to allow average programmers to deliver a wide array
of good applications.
When they designed Java, they knew that they were targetting the middle
of the road... they left out a slew of features which would have made
life easier for more advanced developers and they did it deliberately to
make the language more approachable. Despite that, there are people who
still screw up and they screw up precisely because the language offers
enough freedom to screw up. On balance, that's okay because if it
didn't it would probably be far less functional than it is.
A lot of the backlash that we are seeing against Java right now comes
from the fact that many people are discovering that they can be more
productive without the hand holding, and they are willing to assume
responsibility to leave it behind.
>By contrast, things that we can enforce in code do seem to work pretty
>well. That we also have decades of experience telling us. Garbage
>collection improves on manual memory management. Checked exceptions get
>programmers to write a lot more error handling code than documentation
>ever did. (Not quite as much as they should, of course, but a lot more
>than they used to.) Automated unit tests (ideally run without programmer
>involvement on a continuous integration server) keep programmers from
>breaking the build. Having the source code repository either verify
>formatting or reformat code before checking it in keeps badly formatted
>code from being checked into the source code repository.
>
>These aren't absolutes. They are matters of degree. But they are large
>matters of degree. We know these things. We've learned them through
>experience. Rules we enforce in code and systems are far more likely to
>be followed than rules we merely document.
>
>
the freedom to deal with exceptional cases, or when they do need the
freedom and have it.
Michael Feathers
www.objectmentor.com
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/junit/
<*> To unsubscribe from this group, send an email to:
junit-unsubscribe@...
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
« Return to Thread: Are you really using JUnit during your development?
| Free embeddable forum powered by Nabble | Forum Help |
