In Python it is common to have "doctests" - simple tests inside the documentation of classes and methods. Their main advantage is that they can easily be executed while editing the code - when I change some code, I can run all tests with a single click, I do not have to open another file.

In Java AFAIK there is no "doctest", but a similar functionality can be implemented by just adding to the class a "main" method with some basic documented tests. Then, again a programmer changing the code can immediately run the tests to see if anything is broken.

I haven't seen it done frequently. One possible reason is that it makes the class file slightly larger, but this seems negligible. Are there any other disadvantages to this practice?

  • This is just a case of "different languages have different idioms" and it's usually best to follow the standard idioms when working with the language.
    – kdgregory
    Sep 13 '17 at 11:25

One way of looking at this is that the SRP should generally also hold for files. Usually it is considered good practice to put content related to one specific thing also in one file. In Java this is embodied by the principle to have one class per file. But also in scripting languages without OO support you usually try to limit the size of the file by e.g. splitting up the script in different methods and placing these in separate files. The overarching reasoning being that smaller files make it easier to understand and modify the contents. So from my point of view, having tests in the same file clutters its contents.

However, there are also arguments in favor of having these tests in the same file, especially as part of documentation, as tests significantly help to understand the logic of the code. You also mentioned the easier execution. Note however, that this is not true for many other language with traditionally stronger IDE support (e.g. Java). There I can execute all tests with just one click/hotkey.

In the end it's a matter of trade-offs and personal taste, as it is with so many things in SE.


In common Java setups, source is located in src/main/java and test classes in src/test/java. One benefit of this arrangement is it's relatively easy to not package the test code within a jar when it goes to production. If you wrote the tests within the class file, how would you then strip that code out when shipping production binaries?

Also, technical considerations aside, this just seems unnecessarily messy just for the sake of not having to open another file in an IDE. Software is complicated enough as is, we don't need to introduce further complexity which could have been relegated to a workspace concern.

  • I was thinking that the doctest is just a comment and as such would be removed upon compilation, never reaching the production. Then I remember it's python. 🙄
    – Andy
    Sep 13 '17 at 5:59
  • Regarding the first consideration: isn't it possible to tag some parts of a class as "not for production" and let the compiler handle it? (in C++, for example, it is common to have code surrounded by compiler directives such as "#if DEBUG ... #endif", which are very easy to remove when going to production). Sep 13 '17 at 8:09

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.