<p>JUnit is indeed independent from Maven or Gradle. You can get the jars here: <a href="https://junit.org/junit5/" rel="nofollow noreferrer">https://junit.org/junit5/</a></p>
<p>Once this is added to the classpath, you need to add a run configuration to execute the tests instead of the main program.</p>
<p>IntelliJ IDEA and Eclipse both have integrated support for JUnit (including a small GUI showing the status etc.). I think you do not even have to download something.</p>
<p>Having some kind of kickstart Test as template would surely be helpful. JUnit does not provide such. But the documentation has probably something you can use as blueprint.</p>
<p>Writing tests comes down to apply the JUnit logic to the code to test. This involves some understanding of the JUnit concepts (TestCase, TestSuite, Test Coverage, Test Stub/Scaffold, best practices for writing testable code, etc.) and also knowledge about the JUnit API (all the assert methods). The former probably takes some thought to plan for but giving examples for the API usage should be straight-forward to understand.</p>
<p>If I recall correctly, our programming course had JUnit presented within one or two weeks of lectures and writing tests was not mandatory, except for one lab exam. But there was also a dedicated/advanced course for code tests you could take. This had all the in-depth theory and also lab and a quiz/exam at the end. These are the extreme cases you can have, I think. Supposedly your approach lies somewhere in between.</p>
<p>Having at least heard of JUnit is a benefit even for DevOps, I suppose. Maybe having a small project in which you need to write tests for one selected class only (not all of them) is already sufficient to present some basics.</p>

CC BY-SA 4.0
2024-08-15T13:35:17.877Z
2024-08-15T13:35:17.877Z
Antares
<p>Good on you for adding this into your class!
But I admit that sounds it like a lot in a short time to me.</p>
<p>My only practical thoughts are to (1) provide some starter code that gets the lab project going and also provides some sample tests, and (2) temper your expectations of the tests that the students do produce being very good.</p>
<p>Oh, and give lots and lots and lots of gradle support. For students new to gradle, that is a bit like landing on a foreign planet.</p>
<p>Learning to write tests, at least the mechanical part, isn't so hard if the setup is done and there is a model. JUnit is fairly straightforward!  But learning to create a good test suite takes far longer to learn, and there's as much art to it as science.  You can (and should!) give them some guidance, but I'd still grade that aspect quite gently.</p>

CC BY-SA 4.0
2024-03-24T14:42:15.387Z
Yes, thank you. I might be able to whip up some kind of setup — but isn't that what jUnit (or TestNG) should do out-of-the-box?
Andrew Wolfe
CC BY-SA 4.0
2024-03-23T03:27:43.743Z
2024-03-23T03:27:43.743Z
Ben I.
<p>If you are willing to use TDD, even in an elementary course there is a solution. I've used it, though with older students.</p>
<p>On the first day of the term, give a demo about how to develop a piece of software using test first but with only small pieces of a larger program. Describe how the test tests requirements and then writing a small piece of the program makes the tests pass. One or two tests. A few lines of code.</p>
<p>Then, when you give assignments, instead of giving them as a narrative describing the entire program, divide it up into &quot;stories&quot; as is done in Extreme Programming,</p>
<blockquote>
<p>The display initially has zero value.</p>
</blockquote>
<blockquote>
<p>When a number key is pressed, the display takes that value.</p>
</blockquote>
<p>Etc.</p>
<p>Then have the program built in the order of those stories.</p>
<p>Using this technique you can, in parallel, introduce the programming concepts that you need in the course.</p>
<p>Another way to say this is that you don't, initially, have the students divide up the required program into individual parts/tasks. You do that for them. At some point you can make the stories bigger and require more in problem decomposition but that also helps them understand that problem decomposition and program composition are different if complementary processes.</p>
<p>I also incorporated pair programming into this, but you may not want to go that far.</p>

CC BY-SA 4.0
2024-03-24T15:03:48.953Z
2024-03-24T15:03:48.953Z
Buffy
<p>I was hoping that in this year's Software Engineering class, our capstone for Computer Science, could implement a disciplined automated test strategy for their Java project. Now, with only seven weeks left my students have not gotten that started.</p>
<p>I figured that jUnit, because it's so widely used, would be relatively accessible. However, it seems to have a lot of complexity. Specifically, the inexperienced DevOps students — who only work 18 days before switching teams — would have to dive into Maven or Gradle to get the correct artifacts.</p>
<p>Also, when programming my students would need to ramp up almost instantly on Java annotations, when many of them are relatively inexperienced.</p>
<p>I am dying for some kind of Java unit-testing package that will:</p>
<ul>
<li>easily plug in to a project as one or two JAR files</li>
<li>allow students to adapt their own tests quickly by using a <code>Test</code> interface of some sort</li>
<li>have a minimal framework that will run all the tests and emit the results</li>
</ul>
<p>Maybe there's a wrapper for jUnit that will do this? I don't know.</p>
<p>Thanks in advance for any suggestions.</p>

CC BY-SA 4.0
2024-03-23T11:56:58.063Z
Note that JUnit was developed to support "test first" or "test driven development". Are you willing to do that? An implication is that assignments need to be differently structured.
Buffy
CC BY-SA 4.0
2024-03-23T13:10:09.270Z
Maven and Gradle are popular Java project management and build tools.  Their popularity is well earned, but as far as I am aware, they are not essential to using JUnit, or most other Java frameworks. I confess, that most of my first-hand experience with JUnit dates mostly to before Maven and Gradle existed, but I'm pretty sure you can still do things the old-school way: manually download JARs and put them in the classpath.
John Bollinger
CC BY-SA 4.0
2024-03-24T14:40:09.623Z
@Buffy I've sketched TDD for the class but it's impossible in a 16-week semester.
Andrew Wolfe
CC BY-SA 4.0
2024-03-24T14:41:07.293Z
@JohnBollinger jUnit 5 ("jupiter") doesn't actually list the JARs at all, it basically says "Maven or Gradle"?
Andrew Wolfe
<programming><java><unit-testing>
Are jUnit or TestNG simple enough for undergraduates to apply in a matter of weeks? What alternative?
# Are jUnit or TestNG simple enough for undergraduates to apply in a matter of weeks? What alternative?

(Asked by: username_0 on 2024-03-23)

I was hoping that in this year's Software Engineering class, our capstone for Computer Science, could implement a disciplined automated test strategy for their Java project. Now, with only seven weeks left my students have not gotten that started.

I figured that jUnit, because it's so widely used, would be relatively accessible. However, it seems to have a lot of complexity. Specifically, the inexperienced DevOps students — who only work 18 days before switching teams — would have to dive into Maven or Gradle to get the correct artifacts.

Also, when programming my students would need to ramp up almost instantly on Java annotations, when many of them are relatively inexperienced.

I am dying for some kind of Java unit-testing package that will:

* easily plug in to a project as one or two JAR files
* allow students to adapt their own tests quickly by using a `Test` interface of some sort
* have a minimal framework that will run all the tests and emit the results

Maybe there's a wrapper for jUnit that will do this? I don't know.

Thanks in advance for any suggestions.

**Tags:** programming, java, unit-testing

> **Comments:**
> **username_1**: Note that JUnit was developed to support "test first" or "test driven development". Are you willing to do that? An implication is that assignments need to be differently structured.  
> **username_2**: Maven and Gradle are popular Java project management and build tools.  Their popularity is well earned, but as far as I am aware, they are not essential to using JUnit, or most other Java frameworks. I confess, that most of my first-hand experience with JUnit dates mostly to before Maven and Gradle existed, but I'm pretty sure you can still do things the old-school way: manually download JARs and put them in the classpath.  
> **username_0**: @username_1 I've sketched TDD for the class but it's impossible in a 16-week semester.  
> **username_0**: @JohnBollinger jUnit 5 ("jupiter") doesn't actually list the JARs at all, it basically says "Maven or Gradle"?  

---

## 3 answers

### Answer by username_4 on 2024-03-23. Score: 4

Good on you for adding this into your class!
But I admit that sounds it like a lot in a short time to me.

My only practical thoughts are to (1) provide some starter code that gets the lab project going and also provides some sample tests, and (2) temper your expectations of the tests that the students do produce being very good.

Oh, and give lots and lots and lots of gradle support. For students new to gradle, that is a bit like landing on a foreign planet.

Learning to write tests, at least the mechanical part, isn't so hard if the setup is done and there is a model. JUnit is fairly straightforward! But learning to create a good test suite takes far longer to learn, and there's as much art to it as science. You can (and should!) give them some guidance, but I'd still grade that aspect quite gently.

> **Comments:**
> **username_0**: Yes, thank you. I might be able to whip up some kind of setup — but isn't that what jUnit (or TestNG) should do out-of-the-box?  

---

### Answer by username_1 on 2024-03-24. Score: 2

If you are willing to use TDD, even in an elementary course there is a solution. I've used it, though with older students.

On the first day of the term, give a demo about how to develop a piece of software using test first but with only small pieces of a larger program. Describe how the test tests requirements and then writing a small piece of the program makes the tests pass. One or two tests. A few lines of code.

Then, when you give assignments, instead of giving them as a narrative describing the entire program, divide it up into "stories" as is done in Extreme Programming,

> The display initially has zero value.

> When a number key is pressed, the display takes that value.

Etc.

Then have the program built in the order of those stories.

Using this technique you can, in parallel, introduce the programming concepts that you need in the course.

Another way to say this is that you don't, initially, have the students divide up the required program into individual parts/tasks. You do that for them. At some point you can make the stories bigger and require more in problem decomposition but that also helps them understand that problem decomposition and program composition are different if complementary processes.

I also incorporated pair programming into this, but you may not want to go that far.


---

### Answer by username_3 on 2024-08-15. Score: 1

JUnit is indeed independent from Maven or Gradle. You can get the jars here: <https://junit.org/junit5/>

Once this is added to the classpath, you need to add a run configuration to execute the tests instead of the main program.

IntelliJ IDEA and Eclipse both have integrated support for JUnit (including a small GUI showing the status etc.). I think you do not even have to download something.

Having some kind of kickstart Test as template would surely be helpful. JUnit does not provide such. But the documentation has probably something you can use as blueprint.

Writing tests comes down to apply the JUnit logic to the code to test. This involves some understanding of the JUnit concepts (TestCase, TestSuite, Test Coverage, Test Stub/Scaffold, best practices for writing testable code, etc.) and also knowledge about the JUnit API (all the assert methods). The former probably takes some thought to plan for but giving examples for the API usage should be straight-forward to understand.

If I recall correctly, our programming course had JUnit presented within one or two weeks of lectures and writing tests was not mandatory, except for one lab exam. But there was also a dedicated/advanced course for code tests you could take. This had all the in-depth theory and also lab and a quiz/exam at the end. These are the extreme cases you can have, I think. Supposedly your approach lies somewhere in between.

Having at least heard of JUnit is a benefit even for DevOps, I suppose. Maybe having a small project in which you need to write tests for one selected class only (not all of them) is already sufficient to present some basics.


---

