The colleague is incorrect. Javadoc comments are used to document the intended behaviour of methods and classes. Without a record of this intended behaviour, it will be difficult for other developers to make use of my code. They will also be unable to write tests for it, since if there is no description of the intended behaviour, how can they possibly know what to test for? It is not relevant that the code is only being used internally – if anyone in the company is going to make use of the code or write tests for it, then documentation of the intended behaviour is needed.
Whilst it might be possible to specify the intended behaviour of methods and classes in an external document, this makes it easy for that document to get out of sync with the code, so Javadoc is a preferable way of doing this.
I think my colleague is incorrect. Comments are very useful for understanding code. They will also help me if I need to understand my own code later. They will make writing tests easier and faster. I can record preconditions and postconditions for the code, and these will make it much easier for the testing team later. It is good practice for all developers to document their code.
Unit testing is defined as testing of a small, independent unit of code, such as a single method or class.
We need to be able to maintain our code properly, so we should write comments for all our classes and methods. We need to know what classes and methods are in the code, in case we later need to make changes. Otherwise they will need to ask us what the methods do.
Javadoc is the best tool for this.
In general, this is not good practice. It would be better to avoid duplicated code, and instead factor the common code out (for instance, into a separate method). Otherwise, if requirements for connecting to the database later change, the duplicated code increases the chance that errors will be made (e.g., updating some instances of the duplicated code, and not others).
Since we are using JUnit, a plausible way to factor out the code would be to put it into a “setUp” method in the relevant test classes – JUnit calls this method before each test that is run.
The answer succinctly explains why this is not good practice: it increases the chance for error, later. It does not mention any irrelevant facts or topics.
Unit tests are supposed to be fast, so we should avoid duplicated code – additionally, it violates the “DRY” principle (“Do not Repeat Yourself”). So, this is not good practice, and will cause problems later if requirements for connecting to the database change – we may forget to update one.
We should use a “setUp” method, and connect once to the database, and re-use the connection. Test fixtures are defined as state required for a test – they constitue prefix values supplied for a test.
Tests should be independent of one another. We should use a “setUp” method here, and connect to the database only once, to improve speed. However, repeating the code makes the tests more readable. Testing is defined as an attempt to show our code is correct.