Andrew Spencer

It's worth knowing all the refactoring shortcuts.

For Java:

It's worth knowing all the refactoring shortcuts.

For Java:

Number 13 is an excellent suggestion - I wish teams would spend more time talking about this (actually no, that's not enough - they also need to come to agreement, and then put it into practice).

I don't entirely agree with number 11 - it depends, and I wrote a counter argument a while back, here: http://www.andrewspencer.net/2011/which-language-should-you-code-in/

Number 13 is an excellent suggestion - I wish teams would spend more time talking about this (actually no, that's not enough - they also need to come to agreement, and then put it into practice).

I don't entirely agree with number 11 - it depends, and I wrote a counter argument a while back, here: http://www.andrewspencer.net/2011/which-language-should-you-code-in/

Yes, it's not about whether you use the command line or not (though there's definitely a correlation), it's about attitudes to risk and awareness of long-term viability issues.

I agree with most of the preceding comments, and I think that the answer to the original question is that, even in a corporate environment, youneed both types of people. The conflict that arises between the two tendencies, though frustrating to both, is a symptom of a necessary and healthy process.

Question 9. Do they use Clearcase?

Very funny.

@Dapeng Liu - you're right, but read the 2nd from last paragraph again.

@Daniel Tuchtenhagen - the OP is just being facetious, but here's a serious answer: in code like that, I wouldn't trust anything that the method name tells me. I've already seen methods whose behaviour flatly contradicts their name.

It was a big mistake on Maven's part letting people use plugins without specifying the version (though the kind of mistake that's a lot easier to see with hindsight). At least Maven 3 warns you, as Lieven said.

As an aside, I'd suggest putting the plugin version into the pluginManagement section of the POM, by analogy with what one does for dependency versions.

Hi Jilles,

OK, I was thinking "compile and package" rather than "build". Old habits die hard.

The appropriate way to do it in Maven is to define all that boilerplate in a super POM that can be inherited by every standard java webapp. Then the Maven version is: inherit from super POM, mvn clean install.

So I think your criticism is partly unfair, and partly justified. It's unfair insofar as Java webapps can be done simply with Maven (after all, using a super POM is hardly rocket science).

On the other hand, it's a justified criticism insofar as Maven leaves the developer far too much latitude to do it badly. It's also justified in that Eclipse provides all that functionality off the shelf, whereas Maven doesn't provide a useful mechanism for providing/sharing shrinkwrapped POM configurations (the inheritance mechanism is too unwieldy).

Hi Jilles,

OK, I was thinking "compile and package" rather than "build". Old habits die hard.

The appropriate way to do it in Maven is to define all that boilerplate in a super POM that can be inherited by every standard java webapp. Then the Maven version is: inherit from super POM, mvn clean install.

So I think your criticism is partly unfair, and partly justified. It's unfair insofar as Java webapps can be done simply with Maven (after all, using a super POM is hardly rocket science).

On the other hand, it's a justified criticism insofar as Maven leaves the developer far too much latitude to do it badly. It's also justified in that Eclipse provides all that functionality off the shelf, whereas Maven doesn't provide a useful mechanism for providing/sharing shrinkwrapped POM configurations (the inheritance mechanism is too unwieldy).

Hi Jilles,

OK, I was thinking "compile and package" rather than "build". Old habits die hard.

The appropriate way to do it in Maven is to define all that boilerplate in a super POM that can be inherited by every standard java webapp. Then the Maven version is: inherit from super POM, mvn clean install.

So I think your criticism is partly unfair, and partly justified. It's unfair insofar as Java webapps can be done simply with Maven (after all, using a super POM is hardly rocket science).

On the other hand, it's a justified criticism insofar as Maven leaves the developer far too much latitude to do it badly. It's also justified in that Eclipse provides all that functionality off the shelf, whereas Maven doesn't provide a useful mechanism for providing/sharing shrinkwrapped POM configurations (the inheritance mechanism is too unwieldy).

Tomasz, I agree, and there is another problem with constructors, which is that parameters aren't named (as they are with setter injection). You can get round this by using a builder but then you have even more repetition (so much so that I've never yet found it worthwhile to write one).

BTW I think that shorthand for combining constructor arguments + final fields is Scala's nicest feature when used purely as an improved Java (that is, aside from the features like FP that are totally alien to Java).

Jens, nice article and I will be bookmarking it for use in future arguments debate.

Tomasz, I agree, and there is another problem with constructors, which is that parameters aren't named (as they are with setter injection). You can get round this by using a builder but then you have even more repetition (so much so that I've never yet found it worthwhile to write one).

BTW I think that shorthand for combining constructor arguments + final fields is Scala's nicest feature when used purely as an improved Java (that is, aside from the features like FP that are totally alien to Java).

Jens, nice article and I will be bookmarking it for use in future arguments debate.

Tomasz, I agree, and there is another problem with constructors, which is that parameters aren't named (as they are with setter injection). You can get round this by using a builder but then you have even more repetition (so much so that I've never yet found it worthwhile to write one).

BTW I think that shorthand for combining constructor arguments + final fields is Scala's nicest feature when used purely as an improved Java (that is, aside from the features like FP that are totally alien to Java).

Jens, nice article and I will be bookmarking it for use in future arguments debate.

Tomasz, I agree, and there is another problem with constructors, which is that parameters aren't named (as they are with setter injection). You can get round this by using a builder but then you have even more repetition (so much so that I've never yet found it worthwhile to write one).

BTW I think that shorthand for combining constructor arguments + final fields is Scala's nicest feature when used purely as an improved Java (that is, aside from the features like FP that are totally alien to Java).

Jens, nice article and I will be bookmarking it for use in future arguments debate.

Jilles,

I sympathise with the problems of bad POM authorship, especially copy-paste and dodgy dependencies. This is partly laziness on the part of developers and I think it's unfair to blame it all on Maven (I mean, I've seen plenty of bad Java code, but that doesn't mean I shouldn't code in Java myself) .

The dependency mess, though, is also caused by bad practices by library providers who often don't take care declaring their own dependencies. The plugin configuration mess... well, it's mostly a lack of standardisation, but I'm not sure how it can be improved given that most of these plugins are not produced by the Maven project itself. And the verbosity, that's entirely Maven's responsibility.

What I'm interested in learning is, what would a build tool look like that kept the good points of Maven, but improved on the bad ones?

Jilles,

I sympathise with the problems of bad POM authorship, especially copy-paste and dodgy dependencies. This is partly laziness on the part of developers and I think it's unfair to blame it all on Maven (I mean, I've seen plenty of bad Java code, but that doesn't mean I shouldn't code in Java myself) .

The dependency mess, though, is also caused by bad practices by library providers who often don't take care declaring their own dependencies. The plugin configuration mess... well, it's mostly a lack of standardisation, but I'm not sure how it can be improved given that most of these plugins are not produced by the Maven project itself. And the verbosity, that's entirely Maven's responsibility.

What I'm interested in learning is, what would a build tool look like that kept the good points of Maven, but improved on the bad ones?

Jilles,

I sympathise with the problems of bad POM authorship, especially copy-paste and dodgy dependencies. This is partly laziness on the part of developers and I think it's unfair to blame it all on Maven (I mean, I've seen plenty of bad Java code, but that doesn't mean I shouldn't code in Java myself) .

The dependency mess, though, is also caused by bad practices by library providers who often don't take care declaring their own dependencies. The plugin configuration mess... well, it's mostly a lack of standardisation, but I'm not sure how it can be improved given that most of these plugins are not produced by the Maven project itself. And the verbosity, that's entirely Maven's responsibility.

What I'm interested in learning is, what would a build tool look like that kept the good points of Maven, but improved on the bad ones?

I agree in substance with almost everything you've written in these three posts. In particular the verbosity and inflexibility. About inflexibility, I would add that it's mostly in the fixed nature of the build lifecycle; the plugin architecture gives quite a lot of flexibility, but only up to the point where you need to do something that doesn't fit well with the lifecycle model. And on Maven's good points, let's not forget that there was no standard mechanism for managing library dependencies before Maven was invented.

I do want to take issue with one detail of your criticisms. You dislike that, as soon as you need non-default configuration for a plugin, you find yourself obliged to manage its version. In truth, though, the problem is the other way round. As long as you don't need any non-default configuration for a plugin (and practically everything in Maven is a plugin), then you're leaving Maven to manage your plugin versions.

And Maven does this using a rule that you probably don't want. As I recall, it uses the version in your local repository if there is one, and if there isn't, it downloads the latest. This means you can get breaking changes when you clean your local repository, or build on a new machine, without having changed anything in your code or POM.

Now, that's fine, as long as you don't need your builds to be repeatable...

Nit picking mode: the quote is from Blaise Pascal. Je n'ai fait celle-ci plus longue que parce que je n'ai pas eu le loisir de la faire plus courte (I only made this [letter] longer because I had not the time to make it shorter) http://en.wikiquote.org/wiki/Blaise_Pascal

Nice quote, though, and very apposite to software development.

JUnit users, be warned that the dependency on Hamcrest is broken up to JUnit 4.9 inclusive. The dependency on Hamcrest is declared in the POM - but the Hamcrest classes are also included in the junit-dep jar! So you can never get them off the classpath. This is corrected in 4.10.

An alternative to Hamcrest for writing highly readable assertions is fest-assert. It gives readability on a par with Hamcrest-based asserts, with the extra advantage of using IDE autocomplete. It also works equally well with TestNG.

Neither of fest-assert nor Hamcrest has an unarguable advantage over the other, but both are clearly better than basic JUnit or TestNG assertions, where it's never explicit which parameter is the expected value and which the observed. (And to make things worse, TestNG uses the opposite order to JUnit, just to make sure you've no chance of remembering the order.)

I think the last two comments are missing the point slightly.

Yes, once you've realised that you're missing a case in your unit test, you add the missing line as the two previous commenters said. That is not the point of the article. The point of the article is that (1) human eyeballs will not catch all the missing cases in all the unit tests, and (2) test coverage will not catch them either. Therefore, what other automatable technique could we use? The article offers one approach, but I agree with another previous commenter that mutation testing is probably a less labour-intensive way to get to the same goal.

I take issue with the approach of extracting an interface and writing the stub by hand. With tools like Mockito, you can stub concrete classes. This generally involves less boilerplate than writing stubs by hand. And, it means that we no longer need to program to interfaces for reasons of testability alone.

Programming to interfaces has been promoted as a good design practice, independent of its effect on testability. I held that belief myself not so long ago. With the benefit of greater experience, I now think that it's justified only when there is a genuine need -- in the production code -- for the abstraction that the interface represents. A genuine need means either that we are going to write multiple implementations ourselves, or that we are giving client code the possibility to provide an implementation. If there's only ever going to be one real implementation, I'd stick with a concrete class.

Spring Batch is a good example of a case where programming to interfaces is appropriate: a flexible library, that client code can extend and customise almost without limitation. A service class in a business app, on the other hand, is never going to be exported outside the application, and it's very unlikely that there'll ever be multiple implementations of its API.

Props btw for going to the trouble of writing a stunt double. I've often seen dodgy classes in customers' projects that I've wished I could put in a blog post, if only for the purpose of letting off steam, but I'm too lazy to write stunt doubles. (Or maybe it is just that I can't bring myself to add to the quantity of bad code in the world, even for example purposes. Yes, that must be it.)

Oh, my goodness. I (and colleagues) have been burnt by so many of the things on your list. I think I shall print out a list of the headings and pin it up by my desk.

Truly excellent article. The material would also make an excellent presentation.

There's one thing I'm not convinced of, which is testing whether foreign keys / default values / constraints are working. Assuming you've put them in the schema in the first place, I'm inclined to trust the database to apply them properly. What I don't trust is my own ability to remember to put them into the schema in the first place.

Consequently, I agree that the schema definition should be checked in some way. But how do you assert the correctness of DDL? I don't mean the syntactic correctness (which can be checked by simply executing it), but the semantic correctness. Should column BLABLA.XYZ be constrained to the values 'X', 'Y' and 'Z'? Should PATIENT_ID be a foreign key to the PERSON table? Etc. These are things that no automatic test can know -- unless you tell it, in which case you're simply repeating the information that's already in the DDL. Such a test tells you whether the test and the DDL agree with each other, but it doesn't tell you whether the both of them agree with you.

The approach I favour is: have a single reference schema, which is inspected for correctness by a human. Then, as part of the automatic build, there should be a check that will fail the build if there are any differences between the target schema and the expected schema. This is the direction we're taking on my current team, though we've still got some way to go.

I'd be interested to hear others' opinions on this approach.

The DRY principle doesn't exactly state "it’s better to create a convoluted abstraction than to write different-but-very-similar code twice". Rather, the principle is that every piece of knowledge must have a single, unambiguous, authoritative representation within a system.

Aside from that nitpick, and notwithstanding the disagreements from previous commenters, this article makes a worthwhile point, namely, that automation and removing redundancies often require abstraction, and abstraction can be deleterious.

Your arguments are persuasive. To my mind, the key to a unit test - for whatever definition of "unit" - is that if the test fails it should fail due to an error inside and not outside the unit. Tests are a tool not only for detecting that an error exists, but also for locating it. I wrote about this (from a Java perspective) a little while ago here on DZone.

A corollary to your suggested "building-an-onion" style of testing is that, if a unit depends on another unit, its test should depend on that other unit's test. In the event of failure in a low-level class, the build would skip tests of dependent classes, which might give false positives (is a test failure a "positive" or a "negative"?).

This would avoid the distracting situation where you make 1 mistake in a low-level class and suddenly you get 5 or 10 test failures in completely different layers (not to mention in the integration tests).

On your other point, it's funny but it had never occurred to me that mock generators were an artefact of using a statically-typed language...

Where I'm sitting, a text edit in a JSP, or a single-line change in Java source (without changes to class structure) requires a restart of Tomcat. Granted, it saves rebuilding the project in Maven every time, but it still costs close to a minute each time on my current project, which leaves plenty of room for improvement.

Anyway, that's off topic. Thanks for the article, Felipe. Something I would like to read is a balanced critique of Play!. It has made many choices that are radically different from standard JEE, and the approach is almost diametrically opposed to Vaadin (the most extreme example I know of hiding the web from developers). I wonder what are the advantages and pitfalls of Play!'s approach.

Tom,a decade ago it would have been reasonable to argue that you can't test a class in isolation. But these days, at least in my field, developers are expected to know how avoid hardwiring dependencies.

I totally agree that testing a class in isolation isn't enough - even in the non critical systems I develop - and that you also need to test how classes interact. I call that integration testing, though the term's too broad and I'd be happy to accept a more precise taxonomy.

There's a danger here of confusion between a discussion about what kinds testing one should do, with a discussion about what one means by a term such as unit testing. This has led previous commenters to talk at cross purposes. Stating that unit testing means testing only one class at a time, is not the same as arguing that integration tests are superfluous. Are you certain you're not tilting at windmills?

I've worked on legacy code and enjoyed reading your article.

A factor that progressively slows down development, which you didn't mention, is that programmers sometimes leave and are replaced by other programmers. The author of poorly structured, non unit-tested code can anticipate side effects, far better than a programmer unfamiliar with the code can do. When code is well-structured and unit-tested, the difference in velocity between these two programmers is much smaller.

Thus, good design and unit tests mitigate the consequences of losing knowledge when programmers leave.

I think that managers underestimate how much development is slowed down when a programmer who has lived through the development of a project leaves, and somebody else needs to be brought in during the maintenance phase (the typical scenario). They may understand that we need time to learn the application, but they don't see the time that is lost elsewhere (as you described): more code/deploy cycles, increased number of bugs in QA, increased number of bugs in production... These losses are much greater than the extra time taken simply for coding.

As long as managers underestimate this phenomenon, they'll also underestimate the value of unit tests and careful design. (I am assuming programmer turnover is inevitable, and thinking about mitigating its effects. But reducing turnover in the first place should probably be an even higher management priority.)

Ha. Good observation about comments. I didn't mention them because I'm not sure what is best; I suppose that if you expect all future developers to be Xophone, then you should comment in X. Otherwise, in English.

What I have observed in a 100% Francophone environment is that comments are almost always in French even when the code is partly or wholly in English. Though that's probably more to do with ease of writing, than with consideration for the future maintenance programmer. It's harder to write comments in a foreign language, than it is to name variables.

Ha. Good observation about comments. I didn't mention them because I'm not sure what is best; I suppose that if you expect all future developers to be Xophone, then you should comment in X. Otherwise, in English.

What I have observed in a 100% Francophone environment is that comments are almost always in French even when the code is partly or wholly in English. Though that's probably more to do with ease of writing, than with consideration for the future maintenance programmer. It's harder to write comments in a foreign language, than it is to name variables.

Ha. Good observation about comments. I didn't mention them because I'm not sure what is best; I suppose that if you expect all future developers to be Xophone, then you should comment in X. Otherwise, in English.

What I have observed in a 100% Francophone environment is that comments are almost always in French even when the code is partly or wholly in English. Though that's probably more to do with ease of writing, than with consideration for the future maintenance programmer. It's harder to write comments in a foreign language, than it is to name variables.

Ha. Good observation about comments. I didn't mention them because I'm not sure what is best; I suppose that if you expect all future developers to be Xophone, then you should comment in X. Otherwise, in English.

What I have observed in a 100% Francophone environment is that comments are almost always in French even when the code is partly or wholly in English. Though that's probably more to do with ease of writing, than with consideration for the future maintenance programmer. It's harder to write comments in a foreign language, than it is to name variables.

Thanks.

I had a comment on my blog (same article) from a guy in Germany who said he would always write in English. It got me to thinking that there might be some countries (Germany, Netherlands, Nordic countries) where most programmers' English is good enough to do that. Not in France, though, nor in French-speaking Switzerland.

I'm not sure that the article makes it clear that I'm not talking about multi-national environments, nor software aimed at the world market. I'm more thinking of custom-build enterprise software.

Thanks.

I had a comment on my blog (same article) from a guy in Germany who said he would always write in English. It got me to thinking that there might be some countries (Germany, Netherlands, Nordic countries) where most programmers' English is good enough to do that. Not in France, though, nor in French-speaking Switzerland.

I'm not sure that the article makes it clear that I'm not talking about multi-national environments, nor software aimed at the world market. I'm more thinking of custom-build enterprise software.

Thanks.

I had a comment on my blog (same article) from a guy in Germany who said he would always write in English. It got me to thinking that there might be some countries (Germany, Netherlands, Nordic countries) where most programmers' English is good enough to do that. Not in France, though, nor in French-speaking Switzerland.

I'm not sure that the article makes it clear that I'm not talking about multi-national environments, nor software aimed at the world market. I'm more thinking of custom-build enterprise software.

Excellent idea to use familiar OO code snippets to introduce functional concepts to OO programmers.

It's much easier to start from something we already know, generalise the concept, and give it a label, than it is to start from a label which we don't recognise, describe the concept (which forces us to begin by understanding the abstract, general case), and only then give examples.

@Fuzail Sarang

Ah... I see what you mean, but I'm not convinced that it is useful nor practical to leave the database in a clean state after each test. It is much more reliable to have a setup fixture that can get the database into the required state, no matter what state it starts off in. Keeping the post-test state is also useful for diagnosing failed tests (cf DBUnit's "Best pratice" page).

To put it another way, I think it unwise to start with step 1, and prefer to perform step 4 at the start of each test.

@Fuzail Sarang

Ah... I see what you mean, but I'm not convinced that it is useful nor practical to leave the database in a clean state after each test. It is much more reliable to have a setup fixture that can get the database into the required state, no matter what state it starts off in. Keeping the post-test state is also useful for diagnosing failed tests (cf DBUnit's "Best pratice" page).

To put it another way, I think it unwise to start with step 1, and prefer to perform step 4 at the start of each test.

@Fuzail Sarang

Ah... I see what you mean, but I'm not convinced that it is useful nor practical to leave the database in a clean state after each test. It is much more reliable to have a setup fixture that can get the database into the required state, no matter what state it starts off in. Keeping the post-test state is also useful for diagnosing failed tests (cf DBUnit's "Best pratice" page).

To put it another way, I think it unwise to start with step 1, and prefer to perform step 4 at the start of each test.

@Fuzail Sarang

Ah... I see what you mean, but I'm not convinced that it is useful nor practical to leave the database in a clean state after each test. It is much more reliable to have a setup fixture that can get the database into the required state, no matter what state it starts off in. Keeping the post-test state is also useful for diagnosing failed tests (cf DBUnit's "Best pratice" page).

To put it another way, I think it unwise to start with step 1, and prefer to perform step 4 at the start of each test.

@Fuzail Sarang

Ah... I see what you mean, but I'm not convinced that it is useful nor practical to leave the database in a clean state after each test. It is much more reliable to have a setup fixture that can get the database into the required state, no matter what state it starts off in. Keeping the post-test state is also useful for diagnosing failed tests (cf DBUnit's "Best pratice" page).

To put it another way, I think it unwise to start with step 1, and prefer to perform step 4 at the start of each test.

@Fuzail Sarang

Ah... I see what you mean, but I'm not convinced that it is useful nor practical to leave the database in a clean state after each test. It is much more reliable to have a setup fixture that can get the database into the required state, no matter what state it starts off in. Keeping the post-test state is also useful for diagnosing failed tests (cf DBUnit's "Best pratice" page).

To put it another way, I think it unwise to start with step 1, and prefer to perform step 4 at the start of each test.

@Roger Lindsjö, Chad Retz

Thanks for the tips for disabling constraints in Oracle and SQL Server. I'm thinking this might be a cleaner option than my suggestion, and I'll give it a try on my next project. As long as the constraints are activated before the start of the test, and all constraints checked on reactivation, it'd be safe to do that.

@Roger Lindsjö, Chad Retz

Thanks for the tips for disabling constraints in Oracle and SQL Server. I'm thinking this might be a cleaner option than my suggestion, and I'll give it a try on my next project. As long as the constraints are activated before the start of the test, and all constraints checked on reactivation, it'd be safe to do that.

@Roger Lindsjö, Chad Retz

Thanks for the tips for disabling constraints in Oracle and SQL Server. I'm thinking this might be a cleaner option than my suggestion, and I'll give it a try on my next project. As long as the constraints are activated before the start of the test, and all constraints checked on reactivation, it'd be safe to do that.

@Roger Lindsjö, Chad Retz

Thanks for the tips for disabling constraints in Oracle and SQL Server. I'm thinking this might be a cleaner option than my suggestion, and I'll give it a try on my next project. As long as the constraints are activated before the start of the test, and all constraints checked on reactivation, it'd be safe to do that.

@Roger Lindsjö, Chad Retz

Thanks for the tips for disabling constraints in Oracle and SQL Server. I'm thinking this might be a cleaner option than my suggestion, and I'll give it a try on my next project. As long as the constraints are activated before the start of the test, and all constraints checked on reactivation, it'd be safe to do that.

@Roger Lindsjö, Chad Retz

Thanks for the tips for disabling constraints in Oracle and SQL Server. I'm thinking this might be a cleaner option than my suggestion, and I'll give it a try on my next project. As long as the constraints are activated before the start of the test, and all constraints checked on reactivation, it'd be safe to do that.

@Roger Lindsjö, Chad Retz

Thanks for the tips for disabling constraints in Oracle and SQL Server. I'm thinking this might be a cleaner option than my suggestion, and I'll give it a try on my next project. As long as the constraints are activated before the start of the test, and all constraints checked on reactivation, it'd be safe to do that.

@Roger Lindsjö, Chad Retz

Thanks for the tips for disabling constraints in Oracle and SQL Server. I'm thinking this might be a cleaner option than my suggestion, and I'll give it a try on my next project. As long as the constraints are activated before the start of the test, and all constraints checked on reactivation, it'd be safe to do that.

@Roger Lindsjö, Chad Retz

Thanks for the tips for disabling constraints in Oracle and SQL Server. I'm thinking this might be a cleaner option than my suggestion, and I'll give it a try on my next project. As long as the constraints are activated before the start of the test, and all constraints checked on reactivation, it'd be safe to do that.

@Roger Lindsjö, Chad Retz

Thanks for the tips for disabling constraints in Oracle and SQL Server. I'm thinking this might be a cleaner option than my suggestion, and I'll give it a try on my next project. As long as the constraints are activated before the start of the test, and all constraints checked on reactivation, it'd be safe to do that.

@Roger Lindsjö, Chad Retz

Thanks for the tips for disabling constraints in Oracle and SQL Server. I'm thinking this might be a cleaner option than my suggestion, and I'll give it a try on my next project. As long as the constraints are activated before the start of the test, and all constraints checked on reactivation, it'd be safe to do that.

@Roger Lindsjö, Chad Retz

Thanks for the tips for disabling constraints in Oracle and SQL Server. I'm thinking this might be a cleaner option than my suggestion, and I'll give it a try on my next project. As long as the constraints are activated before the start of the test, and all constraints checked on reactivation, it'd be safe to do that.

@Roger Lindsjö, Chad Retz

Thanks for the tips for disabling constraints in Oracle and SQL Server. I'm thinking this might be a cleaner option than my suggestion, and I'll give it a try on my next project. As long as the constraints are activated before the start of the test, and all constraints checked on reactivation, it'd be safe to do that.

@Roger Lindsjö, Chad Retz

Thanks for the tips for disabling constraints in Oracle and SQL Server. I'm thinking this might be a cleaner option than my suggestion, and I'll give it a try on my next project. As long as the constraints are activated before the start of the test, and all constraints checked on reactivation, it'd be safe to do that.

@Mladen Girazovski
Thanks for the link. I like this approach, the only downside is that XML embedded in Java isn't very pretty - the ideal would be a Java-based format (DSL?). As I understand, this technique is complementary to the DTD-based clean operation.

@Kim Eeckhout
I saw that some people did that. It's more flexible because you don't have to worry either about the order of tables in your test data. The disadvantage is that it's database specific. We use Oracle and I don't think you can even do that in Oracle (though I could be wrong; I am not a DBA).

@Mladen Girazovski
Thanks for the link. I like this approach, the only downside is that XML embedded in Java isn't very pretty - the ideal would be a Java-based format (DSL?). As I understand, this technique is complementary to the DTD-based clean operation.

@Kim Eeckhout
I saw that some people did that. It's more flexible because you don't have to worry either about the order of tables in your test data. The disadvantage is that it's database specific. We use Oracle and I don't think you can even do that in Oracle (though I could be wrong; I am not a DBA).

The main reason Java achieved those things was the control Sun had over the technology: a single language specification, a single set of standard libraries and a single spec for the runtime environment.

It'll be years before we can get anything similar for Javascript, because even if a standard is agreed tomorrow (which it won't be), we won't be able to benefit from it until most users have stopped using the non-standards-respecting browsers. You only need to look at IE 6 to realise how long that can take...

The Maven doc says (I haven't tried it myself) that you need to put "env.SETTINGS" rather than just "SETTINGS" to access an environment variable. Alternatively, you could keep your POM as it is, and supply the variable as a java system property: mvn -DSETTINGS=/path/to/file ... (though by convention, Java system properties are usually lower-case).

I can never get the code formatting right on here either.

The Maven doc says (I haven't tried it myself) that you need to put "env.SETTINGS" rather than just "SETTINGS" to access an environment variable. Alternatively, you could keep your POM as it is, and supply the variable as a java system property: mvn -DSETTINGS=/path/to/file ... (though by convention, Java system properties are usually lower-case).

I can never get the code formatting right on here either.

The Maven doc says (I haven't tried it myself) that you need to put "env.SETTINGS" rather than just "SETTINGS" to access an environment variable. Alternatively, you could keep your POM as it is, and supply the variable as a java system property: mvn -DSETTINGS=/path/to/file ... (though by convention, Java system properties are usually lower-case).

I can never get the code formatting right on here either.

The Maven doc says (I haven't tried it myself) that you need to put "env.SETTINGS" rather than just "SETTINGS" to access an environment variable. Alternatively, you could keep your POM as it is, and supply the variable as a java system property: mvn -DSETTINGS=/path/to/file ... (though by convention, Java system properties are usually lower-case).

I can never get the code formatting right on here either.

The Maven doc says (I haven't tried it myself) that you need to put "env.SETTINGS" rather than just "SETTINGS" to access an environment variable. Alternatively, you could keep your POM as it is, and supply the variable as a java system property: mvn -DSETTINGS=/path/to/file ... (though by convention, Java system properties are usually lower-case).

I can never get the code formatting right on here either.

The Maven doc says (I haven't tried it myself) that you need to put "env.SETTINGS" rather than just "SETTINGS" to access an environment variable. Alternatively, you could keep your POM as it is, and supply the variable as a java system property: mvn -DSETTINGS=/path/to/file ... (though by convention, Java system properties are usually lower-case).

I can never get the code formatting right on here either.

The Maven doc says (I haven't tried it myself) that you need to put "env.SETTINGS" rather than just "SETTINGS" to access an environment variable. Alternatively, you could keep your POM as it is, and supply the variable as a java system property: mvn -DSETTINGS=/path/to/file ... (though by convention, Java system properties are usually lower-case).

I can never get the code formatting right on here either.

The Maven doc says (I haven't tried it myself) that you need to put "env.SETTINGS" rather than just "SETTINGS" to access an environment variable. Alternatively, you could keep your POM as it is, and supply the variable as a java system property: mvn -DSETTINGS=/path/to/file ... (though by convention, Java system properties are usually lower-case).

I can never get the code formatting right on here either.

Héctor, thanks for the link. That article chiefly describes a style of TDD where mock objects are used to drive the design of the system's classes. The authors state that mocks are useful for isolating code from external dependencies (3rd party libraries), as I described, but they see that as only a secondary use.

What they describe is a way of working, that goes beyond what I've written. I like their approach and it is complementary to my suggestions above. However, not everyone will choose to work that way, whereas I've tried to outline principles that will be valid for anyone doing unit testing.

Héctor, thanks for the link. That article chiefly describes a style of TDD where mock objects are used to drive the design of the system's classes. The authors state that mocks are useful for isolating code from external dependencies (3rd party libraries), as I described, but they see that as only a secondary use.

What they describe is a way of working, that goes beyond what I've written. I like their approach and it is complementary to my suggestions above. However, not everyone will choose to work that way, whereas I've tried to outline principles that will be valid for anyone doing unit testing.

Héctor, thanks for the link. That article chiefly describes a style of TDD where mock objects are used to drive the design of the system's classes. The authors state that mocks are useful for isolating code from external dependencies (3rd party libraries), as I described, but they see that as only a secondary use.

What they describe is a way of working, that goes beyond what I've written. I like their approach and it is complementary to my suggestions above. However, not everyone will choose to work that way, whereas I've tried to outline principles that will be valid for anyone doing unit testing.

Héctor, thanks for the link. That article chiefly describes a style of TDD where mock objects are used to drive the design of the system's classes. The authors state that mocks are useful for isolating code from external dependencies (3rd party libraries), as I described, but they see that as only a secondary use.

What they describe is a way of working, that goes beyond what I've written. I like their approach and it is complementary to my suggestions above. However, not everyone will choose to work that way, whereas I've tried to outline principles that will be valid for anyone doing unit testing.

I've had that problem with entities disappearing from Sets and (because I am obtuse and looked in the wrong places) spent ages looking for the source of the bug.

The requirement that objects in a Set have unchanging values for equals() and hashCode() is little known IMO, even though it's in the Javadoc: "Note: Great care must be exercised if mutable objects are used as set elements. The behavior of a set is not specified if the value of an object is changed in a manner that affects equals comparisons while the object is an element in the set." And self-evident when you think for a second about how a hashtable works. But I'm embarrassed to admit I wasn't aware of it.

Incidentally, Effective Java doesn't seem to mention this particular pitfall.

Essentially, it means that you should only put immutable objects into a Set, since

• if you put mutable objects into a set, someday someone who doesn't know about the issue will modify one of the objects and set off a nasty bug;
• if you make immutable those fields used to calculate equals() and hashCode(), but not the other fields, someday someone will change the implementation of equals() or hashCode() without realising the implications and, again, set off a nasty bug.

Unfortunately you can't use immutable fields with Hibernate entities, since even if (like the application-generated UUID) they are conceptually immutable, Hibernate needs a setter method to be able to restitute them from the database.

Consequently, if you ever put Hibernate entities into a Set, there's no way to circumvent the risk of a bug. I'd be interested to know if anyone else has come to the same conclusion.

It's been a pleasure reading this discussion.

I would like to add Vaadin to the list of UI frameworks, as an example of a framework that operates in terms of interfaces but provides an abstract class which virtually all components extend in practice.

I haven't the experience with framework design to know which approach least constrains framework evolution. But as a user of UI (or any other kind of) frameworks, I prefer them to define interfaces, since it is easier to mock interfaces for testing. (That goes against the principle that one shouldn't modify one's code to make it testable, but I don't really agree with that principle anyway.)

I prefer to dig into the source, when I need to understand some code: it's more reliable. That's why I place a relatively low importance on comments, and more importantly, a very high importance on intention-revealing code. The only time I look at the Javadoc before the source code is with published (i.e. library) code. Not for "public" methods that are, in reality, private to the project in which they occur.

I do agree that you need to know what the method does, which value it returns, etc.; it's just that for the type of class I illustrated, I don't think you need a comment to tell you these things. In other cases - perhaps the type of class you are thinking of - you sometimes need to comment even a private method.

Of course, if enterprise Java were done using object orientation, these classes with no behaviour but only Javabean properties wouldn't exist. But that's another subject.

My post was only intended as a complaint about something that annoyed me, but the replies have made me realise that the lesson is this:
Whether or not a method depends on the method and its context, and is a decision that needs to be made intelligently by the developer. It can't be made by any wizard or quality metric, nor (IMO) by a blanket statement such as "All public API must have Javadoc comments."

I prefer to dig into the source, when I need to understand some code: it's more reliable. That's why I place a relatively low importance on comments, and more importantly, a very high importance on intention-revealing code. The only time I look at the Javadoc before the source code is with published (i.e. library) code. Not for "public" methods that are, in reality, private to the project in which they occur.

I do agree that you need to know what the method does, which value it returns, etc.; it's just that for the type of class I illustrated, I don't think you need a comment to tell you these things. In other cases - perhaps the type of class you are thinking of - you sometimes need to comment even a private method.

Of course, if enterprise Java were done using object orientation, these classes with no behaviour but only Javabean properties wouldn't exist. But that's another subject.

My post was only intended as a complaint about something that annoyed me, but the replies have made me realise that the lesson is this:
Whether or not a method depends on the method and its context, and is a decision that needs to be made intelligently by the developer. It can't be made by any wizard or quality metric, nor (IMO) by a blanket statement such as "All public API must have Javadoc comments."

I prefer to dig into the source, when I need to understand some code: it's more reliable. That's why I place a relatively low importance on comments, and more importantly, a very high importance on intention-revealing code. The only time I look at the Javadoc before the source code is with published (i.e. library) code. Not for "public" methods that are, in reality, private to the project in which they occur.

I do agree that you need to know what the method does, which value it returns, etc.; it's just that for the type of class I illustrated, I don't think you need a comment to tell you these things. In other cases - perhaps the type of class you are thinking of - you sometimes need to comment even a private method.

Of course, if enterprise Java were done using object orientation, these classes with no behaviour but only Javabean properties wouldn't exist. But that's another subject.

My post was only intended as a complaint about something that annoyed me, but the replies have made me realise that the lesson is this:
Whether or not a method depends on the method and its context, and is a decision that needs to be made intelligently by the developer. It can't be made by any wizard or quality metric, nor (IMO) by a blanket statement such as "All public API must have Javadoc comments."

I prefer to dig into the source, when I need to understand some code: it's more reliable. That's why I place a relatively low importance on comments, and more importantly, a very high importance on intention-revealing code. The only time I look at the Javadoc before the source code is with published (i.e. library) code. Not for "public" methods that are, in reality, private to the project in which they occur.

I do agree that you need to know what the method does, which value it returns, etc.; it's just that for the type of class I illustrated, I don't think you need a comment to tell you these things. In other cases - perhaps the type of class you are thinking of - you sometimes need to comment even a private method.

Of course, if enterprise Java were done using object orientation, these classes with no behaviour but only Javabean properties wouldn't exist. But that's another subject.

My post was only intended as a complaint about something that annoyed me, but the replies have made me realise that the lesson is this:
Whether or not a method depends on the method and its context, and is a decision that needs to be made intelligently by the developer. It can't be made by any wizard or quality metric, nor (IMO) by a blanket statement such as "All public API must have Javadoc comments."

@everybody Thanks for all the comments, including -- no, especially -- the ones I don't agree with. :) You made me realise there's quite a lot that can be said about the subject.

@Carlos Hoces "All public, well constructed API must have Javadocs"
I've seen this assertion elsewhere -- including the Sonar rules at the organisation I work in -- and I'd be interested to read a justification for it. I don't adhere to it, though that partly depends on the definition of "public". (The keyword "public" doesn't itself say much about how widely disseminated the code will be.) Here's why.

In the example I quoted, we're talking about a transfer object which is only shared between the service and web layers of the same project. It contains only Javabean accessor methods, no business rules, and the only words in the method names, besides "get" and "set", are application-wide business terms. And while those terms do need defining, it's not clear that this class is the best place to do so (admittedly that depends on context, and in some contexts it might be the right place). So, in this example I don't believe that there's a clear need to provide more than what the method names have already given us.

For code intended to be re-used outside the scope of its own project, I agree that you should usually expect to see some documentation in the Javadoc comments. Even in this case, however, I maintain that a comment that only repeats information coming from the method signature adds no value, and something that adds no value should not be in your code. So: either you need more than the method signature, and you put what's needed in the API comment, or you don't need anything more, and a comment is not justified.

Btw I totally agree with you about preferring verbose to concise code.

@Adam Davis: from an accuracy point of view, you're right, and if the code maintainer uses the IDE's refactoring tool, they'll probably stay accurate even through method renaming. I'm arguing that they're bad because of the processor cycles that they waste in the developer's brain, making the effort to ignore them.

Certainly, this is much less bad than actively misleading information, and if these pointless comments only took up 10% or so of the source code, I wouldn't mind so much. But in the example I gave, there are 6 lines of genuine information (package statement, four properties, closing brace), 18 lines of accessor method (arguably redundant, but we can all agree that Java does require them, unless we use Lombok), ten lines of whitespace (very necessary IMO), for a total of 34 lines that are pulling their weight. The overall source file is 94 lines, if we ignore the sarcastic little comment I added at the bottom, so that's... wait for it... sixty four percent of noise.

OK, I'm being slightly unfair. The class comment does mention that it is not just any Coordonnee, but a coordonnée physique (good luck for guessing what that means), but in any case, it's well over half junk, which is far too much. And to make matters worse, the junk is distributed towards the top of the file.

@Mladen Girazovski and Cosmin Mutu: the language question deserves a discussion all to itself. I'm currently working for public-sector administration that governs an entirely monolingual area and that, in addition, is linguistically self-determining (so I don't have to worry that a higher authority might require it to produce translations of all administrative business into Vulcan, for instance). All development is done on-site or by French-speaking partners.

In these circumstances, I give precedence to the practice of using business vocabulary, which is in French, for all business elements in the code, but sticking to English for purely technical elements. This makes for a bastard mixture of technical words like "set", "get", "forward", with business terms like "Personne", "Adresse", "Medecin". I've tried the alternative, which is to use English translations of all the business terms referred to in the code, but this is far more problematic... I can explain in detail if you would like, but I don't want to bore anyone. :-)

If you were working with a multi-lingual team, or for a multi-lingual organisation, I agree that the code would have to be in English; but in that case, the business vocabulary would probably be in English already.

Btw I'm English myself, although I do worry that living in France might have polluted my English writing style.