After you've imported code as a new project, IntelliJ will bring you to its editor view. It will probably have a "Build" tool window open at the bottom showing you its progress as it sets up the Gradle project:
In the center of the screen is the main editor. Currently, no files are open, so IntelliJ just shows some useful(ish) keyboard shortcuts.
Notice that there is a toolbar on every side of the window (we won't count the menu bar at the top and the status bar at the very bottom as toolbars). The top toolbar has some buttons for running code and using Git (and some other buttons), but the other three toolbars just contain buttons for showing or hiding tool windows.
Feel free to play around with these tool windows. IntelliJ lets you show or hide tool windows by clicking on their button in the toolbars, and also lets you resize them normally. You cna also drag the tool buttons around to rearrange the tool windows. There are other display options you can find by right-clicking the tool buttons or clicking the gear icon on the upper-right corner of a shown tool window. You can click the "Help" item in that menu to open the official documentation for more details.
If you accidentally close a tool window, you can reopen it by going through "View" > "Tool Windows", which will list out all the tool windows. You can also reset all tool windows by clicking "Window" > "Restore Default Layout".
It's also possible that your tool window bars become hidden; in this case, simply click "View" > "Tool Window Bars" to restore them. (Other elements of the IDE can be hidden or shown in the same way.
As mentioned already, IntelliJ will automatically open the "Build" tool window upon importing a Gradle project/module; feel free to minimize it now, since it's usually not very useful.
Now take a look at the the "Project" tool window on the left. This tool window lists out all the modules in your project, and all the files in those modules, as well as external libraries used (all of which should now be automatically downloaded by Gradle, with the exception of the JDK itself). You can expand folders by double clicking its row in the tool window or by clicking the triangle icon to the left of the folder icon.
Expand the src/main/java/misc/sanity
folder, then double click the
SanityCheck
file to open it in the editor.
If you have Checkstyle set up properly, there should be 5 Checkstyle errors in this file, each of which should be marked as an error (i.e., there should be red squiggly underlines). You don't need to count them up; instead, just open the "Checkstyle" tool window. By default, there won't be anything in it, but if you click the green play-button-shaped triangle on its left side, it will display all Checkstyle errors in the currently-active file.
Below that button are two more buttons for showing checkstyle for all files in the current module and for all files in all modules respectively. Both should do the same thing right now, since you probably only have one module in your project. Click either button now.
You can see now that some errors in MapProblems.java
, LinkedIntListProblems.java
, and IntTreeProblems.java
also get picked up.
None of these style errors should affect our ability to run code, however. Right-click the
SanityCheck
file in the "Project" tool window, then click
"Run 'SanityCheck.main()''" to run it.
If you have your JDK settings properly working, you should get output like this:
Also note that the "Add Configuration..." dropdown that was previously in the top toolbar now
says "SanityCheck" instead, and that the green play button to the right of it is now enabled.
If we click that, IntelliJ will run SanityCheck.main()
again. That dropdown
should automatically select the file that was run last—IntelliJ will automatically save
data about which files you run as "run configurations."
You can click the dropdown to select which run configuration the play button and bug button to the right will use. (There won't be any other configurations right now, though.) The play button will run that configuration normally, just like what we just did, whereas the bug button will run it in debug mode, which we'll talk about on a different page.
Open MapProblems.java
from the problems
package source code.
src/main/java
is the root folder for Java packages in our assignments, or at
least for the source code.
MapProblems.java
is a Java class with some method stubs (they're not implemented yet); such a class with only normal methods cannot be run on its own. However, if we want to make sure our code is working properly,
we'll need to run it somehow, and it's not always feasible to check that a small part of
or code works properly by running the entire program.
This is where tests come in: tests are an easy way of running just a small portion of code. Often, tests will focus on a single method at a time.
Find the TestMapProblems.java
test file from the datastructures
package
in the "Project" tool window (tests have a different root folder: src/test/java
),
then run it by right clicking it in the tool window, and then clicking
"Run 'TestMapProblems'".
The "Run" tool window should pop up. (Also, the selected run configuration in the top toolbar should change to "TestMapProblems".)
For tests, this window is split into two panes: the left lists out the names of all tests that were run, and the right is the console output and other details about the test. By default, the name of the test file is selected, and the right pane displays output from all tests, but you can click a test name to show output for only that test.
Currently, MapProblems.java
isn't implemented yet, so all the tests are
failing, as indicated by the red exclamation mark icon next to their names. Double-click a test
name to open the test file at the failing line.
In the next part of the assignment, we'll start getting the tests to pass as we implement these methods. You don't have to fully understand all the tests for Homework 1, but TestMapProblems.java
and TestLinkedIntListProblems.java
are good test files to start with. If you're curious right now, you can read the
page on JUnit tests
understanding the tests and also ask to go over the tests at office hours. Reading and writing testing code is something that will come up in the future - frequently in this course and in many industry contexts.)