Java habits for the main method

Question

I write code primarily for personal use, but I am considering releasing an application (scientific modeling / visualization) that I originally developed for personal use.

One of my habits is to use the main method in classes to test class performance in isolation. I believe that this is probably bad to some extent (as, no doubt, various other habits stemming from self-learning and the scientific development environment). However, this was never a self-service issue that I noticed.

Would you be so kind as to confirm (or deny) that network distribution is a problem for an application released to the scientific community (the source will also be open), and if so, why?

EDIT: playing the devil's lawyer (okay, my lawyer) compared to some of the answers suggested: the “use of the application” part is expected to be a small-scale modification of the source code by non-developers (typical scientists). I know that on the receiving side, that having tests for a class built directly in this class would be quite simple for me to recognize and modify accordingly (especially if it was consistent for classes). Does something like JUnit use the same utility, referring to the audience?

MAKE A DECISION: I think the KLE answer is the best balance of careful and concise, so I chose it, but I think the comments on the discussion in Bill are also very useful. I also don’t understand why Johannes’s answer was rejected - the perspective of “how this work” is very important for the coders of the scientific community, while other answers point to various reasons why individual unit tests are probably more useful. than my current habit, they don’t actually consider this use, so his answer is far from "useless." Thanks to all current (and future) respondents, and here, to wish there was a way to combine multiple answers as the correct answer!

Answer 1

JUnit allows you to run tests, just like on your network, but also:

• Usually usually only one method is used, which can become real big ; if you extract small methods used only for the test, there is a risk of using these methods in regular code
• does not clutter the class itself with the help of testing methods , they are in another class
• allows inheritance in classes (the main one, like a static method, cannot be inherited or reused); As a rule, the installation before the actual test can be quite long, and its reuse is, of course, wonderful.
• the main result does not have (success or failure), only a way out; you need to manually check the result to determine the result , and perhaps understand it
• allow you to perform several tests at once (class, package, project, everything), which is necessary for regression testing (or you will spend your second day in a row one after another)
• JUnit provides many additional functions out of the box , for example, how some tests are ignored, checking that the test is not too long, provide several launching interfaces, etc.
• you can reuse multiple tests for each implementation or subclass (for example: checking Liskov substitution), which allows you to test a lot without supporting a lot of test code.

Answer 2

Testing your class using its own main method is bad, because it gives the class additional responsibility (testing itself). Tests should take place in separate classes, preferably using a test library such as JUnit .

Distributing the network (I like the phrase you came up with) also makes it more confusing for the developer to find the entry point to the application when they approach it for the first time.

Answer 3

First of all, it's great that you write tests. I do not really like the approach to the main method in many classes of the project. I would recommend moving the test code and using a testing platform. This makes it easy to clean up the source code, and if you use a consistent name method for your test classes, it’s easy to find related tests.

Answer 4

This is not scary, but it is not recommended for two reasons:

• This can allow users to do what you don’t want, or at least give them an idea that they can do something you didn’t like; and
• Prolific main () methods are often a poor replacement for unit tests.

This is (2) you should really focus.

Answer 5

You need to use a testing tool such as JUNIT to perform testing on your classes, and not to insert testing code into your production code.

This purely separates the tests from your code.

Answer 6

There is nothing wrong with this approach, but there is a big flaw: every main() method must call every time to test all your code. Most likely, you will not do it. This is too much noise. In addition, you should know which main() methods are real entry points and which are tests. This is not entirely obvious.

With JUnit and similar tools, you can mark the code as "this is a test." This allows the tool to automatically find all the tests in your project and run it all at once. Thus, the chances are much higher than you will run all the tests most of the time, and errors will be detected earlier.

Answer 7

I would not use the basic methods in all classes for testing purposes. Firstly, to follow the principle of sharing concerns (use and testing are different problems), and because we have elegant solutions for testing.

Secondly, and this has not yet been mentioned, if each class has a main method, it is quite difficult to find the "real" entry point into the application. If I see a class with a main method, I expect this to allow me to “use” the class in my own way. I do not expect this to run a test case (possibly with serious side effects).

And, this is only the third aspect that comes to my mind: the main methods are always publicly available, so your library user can use these methods at any time, even while executing his own application. This can have terrible side effects, especially in multi-threaded environments.