- A. Windows Setup
- B. OS X and Unix Setup
- C. Running JUnit Tests from a Terminal
- D. Running the Style Checker from the Terminal
For those of you who don’t want to use IntelliJ, this is an unofficial supplemental guide on how to run JUnit tests from the command line. Because we’ve switched over to IntelliJ, the staff has not been trained in these instructions, and will not provide official support for this approach, though some staff members will be able to help.
In order to run JUnit tests from the terminal, you’ll need to have your computer setup to use the Spring 2017 Java libraries.
To download the files, all you need to do is pull from the skeleton repository
git pull skeleton master. Your javalib directory should contain the
A. Windows Setup
Pull from the skeleton repo and verify that you’ve received a javalib folder containing the files listed above.
- Create a CLASSPATH environment variable pointing to the javalib folder. As
we did in Lab 1b, we will do this by updating our environment variables:
Windows 10/8/8.1: Launch the Start Screen by pressing Windows, and type ‘Environment Variables’. Select “Edit the system environment variables”. Windows 7 and earlier: Open the Start Menu and launch the “Control Panel”. Search for “Environment Variables”, and select “Edit the system environment variables”.
Navigate to the “Advanced” tab, and click “Environment Variables…”.
Under “System variables”, click “New…”
Define the following variables – if the variable already exists, select the variable and click “Edit…”, then add the value specified below to the front of the value, followed by a semicolon; otherwise, click “New…” and use the values specified below as the value of the variable:
- CS61B_LIB: Set this to the location which contains your library
JAR files (e.g. stdlib package.jar). This is the location you
specified in step 1. In my case, I have specified the location
C:\cs61b_libraries. Since you downloaded the libraries using git, your directory will probably be something more like
C:\Users\potato\cs61b\abc\javalib. Warning: If the path to the above directory contains space(s), this will most likely go miserably for you. You should do anything in your power to avoid having spaces in your folder names for path purposes.
- CLASSPATH: Set this to
- CS61B_LIB: Set this to the location which contains your library JAR files (e.g. stdlib package.jar). This is the location you specified in step 1. In my case, I have specified the location
- Press OK to save these settings, and OK again to close the dialog for System
Properties. Restart any open Git Bash/Command Prompt/Cygwin windows that you
have open and you should be good to go. To verify that your setup works, try
ArithmeticTest.javafile from lab3. If this file compiles, everything is working as expected.
B. OS X and Unix Setup
Video Instructions (Spring 2016)
Navigate to your repository in the command line, pull from the skeleton repo with
git pull skeleton master, and verify that you have a
javalib/folder containing the jar files listed above.
Navigate to the javalib folder in your repository and enter in the command
pwd. You should get something that looks like
/Users/Dennis/school/cs61b/sp2016/aaa/javalib. Copy this to somewhere (for pasting purposes)!
- Set up a CLASSPATH environment variable that points to the javalib folder. To
Open the file .bashrc in your home directory. Since the filename starts with a period, it counts as a “hidden file”, and will not appear in your Finder window. Annoyingly, there is no “show hidden files” option in Mac OS X, so I recommend opening this file by creating a terminal window and entering the command
pico ~/.bashrc. This will open the pico editor, which is fairly easy to use (compared to vim or emacs). Or you can use sublime or whatever else you’d like to use.
Copy the result you got from step 2 above to the clipboard.
Scroll to the bottom of your .bashrc file. If it is empty, this is fine. It just means that you didn’t have one yet. At the bottom of your .bashrc file, add:
export CS61B_LIB_DIR="[paste result from step 2 above]/*"(note the asterisk at the end), but with the directory name adjusted to match the location of your javalib folder. So, if I use the result that I got above, I would add:
export CS61B_LIB_DIR="/Users/Dennis/school/cs61b/sp2016/repo/javalib/*"to my .bashrc file. This creates an environment variable called
Now add a line to the bottom of your .bashrc file that says
export CLASSPATH="$CLASSPATH:$CS61B_LIB_DIR:./". This creates an environment variable called CLASSPATH. Everytime you use javac, it will look in the directories given by the CLASSPATH for library files (you do not need to manually import libraries in Java code).
- Check to make sure your .bashrc is correct. Starting from an empty
.bashrc, I would end up with this at the bottom of my file:
export CS61B_LIB_DIR="/Users/Dennis/school/cs61b/sp2016/aaa/javalib/*" export CLASSPATH="$CLASSPATH:$CS61B_LIB_DIR:./"
Press Ctrl-O to save. Then press Ctrl-X to exit pico.
Now, open the file .bash_profile in your home directory with
Again, scroll to the bottom of the file and add on a new line:
- Press Ctrl-O to save. Then press Ctrl-X to exit pico.
Restart any terminal windows you have open.
- Open a new terminal window and verify that your code is working by compiling
ArithmeticTest.java from lab3 with
javac ArithmeticTest.java. If this works without errors, then your computer is properly configured.
Note: For Unix users, you might need to tweak these steps slightly if you’re using a different shell than Bash. If you don’t know what that means, then these directions should almost certainly work (but have not been tested).
C. Running JUnit Tests from a Terminal
Rather than write your own main method that manually invokes every test (e.g.
testProduct), we’ll use the trick from Lecture 7 where our main
method simply calls a
runTests method that is able to automatically identify
and execute all test methods annotated with the
In 61B, all JUnit tests files should have a main method that calls
jh61b.junit.TestRunner.runTests, with an argument equal to the name of the
class. For example, if your JUnit test file is called ArithmeticTest.java, your
main should simply be:
This line is invoking the
runTests(Class c) method of a class called
TestRunner in a library called
You don’t need to know how this mysterious TestRunner class works (but see the
Spring 2016 lecture 7
Just know that this function will run all of the methods which are preceded by
@Test in the specified file, and will output everything in a nice format.
Let’s try it out. Go to the lab3/Arithmetic folder, and try running the small test provided:
javac *.java java ArithmeticTest
This will run all of the tests in ArithmeticTest.java and give you back a JUnit
report. Notice it includes a failure! This tells you which test failed
ArithmeticTest), what the expected and actual values were, and
on what line the failure occured. The output on your console should be something
Running JUnit tests using jh61b.junit.TestRunner in "all" mode. Running testSum: ==================================== expected:<11> but was:<30> at ArithmeticTest.testSum:25 (ArithmeticTest.java) =====> FAILED! Running testProduct: ==================================== =====> Passed Passed: 1/2 tests.
As you can see above the
testProduct test passed with flying colors. However,
testSum class failed miserably, apparently calculating 30 when it should
have computed 11.
ArithmeticTest.java and take a look around. Comparing against the
output above, you’ll see that even though
testSum included many
statements, you only saw the first failure (even though all of the later asserts
would have failed as well!)
This is because JUnit tests are short-circuiting – as soon as one of the asserts in a method fails, it will output the failure and move on to the next test.
ArithmeticTest so that it shows only failed test results (by
changing the mode argument from “all” to “failed”). Re-run and you’ll see only
failed tests. We recommend that you run your test files in “failed” mode, as
this will allow you to focus on what needs doing, rather than celebrating what
has already been done. Debugging is a hard life.
Now it’s time to look to see why
testSum failed. Look at
testSum to understand what its testing for, and then make the appropriate change in
After fixing the bug, execute the compilation and execution commands again:
$ javac *.java $ java ArithmeticTest
If you’ve fixed the bug, it should look like this:
$ java ArithmeticTest Running JUnit tests using jh61b.junit.TestRunner in "failure" mode. Passed: 2/2 tests.
Since you’re running your code from the command line, you’re going to need to use print statement debugging (as opposed to the cool debugger you hopefully saw in lab 2). Any code that is printed during a test will be output as part of the results message for a given test. Try adding print statements and see how the output changes.
Extra for Experts: If you’re interested in learning to use a command line debugger for Java, you can try out Paul Hilfinger’s gjdb tool. See this video from Spring 2015 for a demo of this tool. Due to very low adoption rates in previous semesters, we will not provide official support for this tool, but lab1d and lab3 from Spring 2015 explain how to use it. The directions from Spring 2015 should still work (but let Josh know if they don’t).
D. Running the Style Checker from the Terminal
We will not be supporting the command line style checker in the Spring of 2017. If you want to use it, see the Spring 2016 directions. The needed files can be found in the Spring 2016 skeleton repository.