I don't like unnecessary inheritance in tests.
I'm not wild about them either, but one works with what one's got.
what if we'll have tests which shouldn't go over 10 secs, and others (i.e. true unit tests) which shouldn't exceed 2 secs
The current layout in HDFS is to have separate directory trees for the integration and (currently sparsely populated) unit tests. This implies we wouldn't be commingling the two types in the same file, and this approach is predicated on that assumption. I'm ok with either approach, but if we're going to be combining types, we probably should collapse the directory trees sooner than later.
If, on the other hand, we're separating unit and integration tests into different files, this approach has the advantage that one can apply the rule to an entire file with only one line (assuming the test is JUnit 4), rather than having to mark each and every test case with the same annotation. This approach thus has a smaller burden on the test writer and on any refactoring we may want to do to implement it.
Also, it would be simple enough to write a script as part of test-patch to verify that all tests in /unit are so marked and thus eligible to be in the unit category (although, it also wouldn't be prohibitively difficult to write one to check each @Test annotation to include a timeout value).