I've been learning C# lately to see the other side of the coin (I have a decent amount of Java knowledge already) so I've been reading up on C#, and I came across an article called C# for Java Developers, and in reading the article, I saw something that I had never heard before.

It is typically recommended that one creates a main method for each class in an application to test the functionality of that class besides whatever main method actually drives the application.

I've never done commercial development, so maybe this is an industry practice that I just haven't heard of, but surely somewhere in the various books I've read it would have come up.

Is this really a thing? Is it common to do this?

  • 1
    see Discuss this ${blog}. Wonder why do you use obscure blogs instead of normal authoritative tutorials
    – gnat
    Sep 11, 2016 at 18:17

3 Answers 3


Most developers use a testing framework, such as JUnit, for their tests. These (so far as I now, there may be exceptions) do not require writing a main() for every class.

If you are not using a framework, it might make sense to do testing via a main(). However, don't do that. Use a testing framework. It makes your life way easier, allows for continuous integration, test/code coverage and metrics, lots and lots of good stuff.

Note: For a GUI class, I will sometimes write a main() to bring up the custom MySuperWidget in a JFrame and show it off for quick visual testing. This is an exception, not the rule.

  • A testing framework also allows you to separate your test code from production code, which (1) makes it easier to find whichever you're looking for at a given time, and (2) allows you to put your code into production without its tests (which is often beneficial, as the tests often end up taking a lot more space than the code itself) Sep 11, 2016 at 18:47
  • Good point - as a few more "here are good things about testing frameworks" comments come in, I'll update and improve the answer.
    – user949300
    Sep 11, 2016 at 19:00
  • For a Swing class, I'd sooner make a separate class with a main method inside the test module rather than add the main directly to the component class.
    – jwenting
    Sep 12, 2016 at 7:23

First thing to note that posted article blog is quite old. It is dated 2001. This is important, because that quote talks about specific thing : unit testing. I'm not old enough to comment on state of unit testing at the time, but looking at something like this, JUnit (the official way to unit test Java applications) was only one year old. Not old enough to be within common programmer's repertoire. So at the time, giving each class a main method so it can be unit tested might seem like a good idea.

Now, we use proper unit testing framewroks. JUnit for Java. NUnit/XUnit for .NET

Also, that article is really old. I wouldn't trust anything written in there just based on that fact. Things develop extremely fast in programming world.

  • +1. In 2001, Java was less than a decade old. Now, it's well on its way to starting its third decade. C# was totally brand new, released just in time to coincide with Windows XP. Both languages have changed, the ecosystem around them has changed, and the recommended practices for using them have changed. Sep 11, 2016 at 18:51
  • 4
    While I agree with this, I've never liked using "that's old, we do it this way now" as an explanation. Sep 11, 2016 at 20:49
  • @CandiedOrange I didn't meant it like that. I meant it more in the sense "Be skeptical of old practices, because there might be new practice developed since then". As for "Why is new practice better" is completely different question.
    – Euphoric
    Sep 12, 2016 at 4:23
  • 2
    I'm sure you didn't, but the way I mean it is, understand why old practices aren't current or someone will slap a new name on them and sell them to you again. I don't mean to snipe but as you have the most upvoted answer It'd be nice if it explained why we don't do this anymore. It's certainly not because JUnit told us to. Sep 12, 2016 at 4:29

It is a thing. People do this. It's not common if you follow a simple rule:

Remove dead code.

People have lost entire companies because unused code was left lying around. Then an update sends a bit of logic down a path that hadn't been executed in years and suddenly it's trading stocks with strategies from the 90's.

We don't like code in our operational environments that isn't used there. That's why we put tests in a separate class. If you want, you can choose to ignore the remove dead code rule. If you do, stay away from my stock portfolio.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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