Using IntelliJ
On writing code, debugging code, and running tests in IntelliJ.
Table of contents
Welcome to IntelliJ IDEA! This guide will provide an interactive overview of how to use IntelliJ to work on homework 1. As the quarter moves on, we’ll learn more advanced features of IntelliJ. For complete documentation, refer to the IntelliJ online help reference.
After you’ve imported code as a new project, the default user interface looks as follows.
The Editor
In the center of the screen is the Editor. No files are open, so IntelliJ just shows some common keyboard shortcuts. To open a file, look to the left of the editor for the Project tool window, which shows the structure of the project. Open SanityCheck.java by double-clicking inside of the src/edu.washington.cse373 folder.
The SanityCheck class will appear in the editor. This class contains a number of Checkstyle violations. Expand the Checkstyle tool window at the bottom of IntelliJ. By default, there won’t be anything in it, but tapping the green play icon on the left side of the Checkstyle tool window will display all Checkstyle errors in the current file. (You may need to set the Rules to the “CSE 373 Checks” that we setup earlier.)
For most homeworks, a percentage of the final score is allocated to code style. However, unlike CSE 143, our code style is managed entirely by Checkstyle. Once you resolve all of the Checkstyle violations, you will receive full credit on the style portion of an assignment.
Running Code
None of these style errors should affect our ability to run code, however. Next to the main() method, there should be a green play button that allows you to run code. After clicking it and running SanityCheck.main(), you should see results similar to this:
Running Tests
Open the intlist/test/LinkedIntListTest.java file from the Project tool window. This class consists of many unit tests, each of which tests a small unit of your program’s behavior. Run the unit tests by following the same procedure as we did for running code: click on the play button by the LinkedIntListTest class, and choose Run 'LinkedIntListTest'.
Did you notice that LinkedIntListTest does not have a main method, and yet IntelliJ was still able to run the tests? Because unit testing is so popular, the developers of IntelliJ added a feature to automatically detect test files and treat them differently. Notice that LinkedIntListTest has a red-green diamond next to the file in the Project tool window, designating that IntelliJ recognizes the class as a collection of unit tests. This allows us to run individual tests. Try running only testSquare by tapping the green play icon next to the line number 11.
Debug Mode
IntelliJ includes a built-in debugger, and we’ve enhanced it by installing the Java Visualizer plugin. We can run the program in debug mode by choosing Debug ... instead of Run .. when you click on a play icon. Like jGRASP, the IntelliJ debugger runs your program exactly like it would when running it normally, but it allows you to pause execution on breakpoints. Let’s try this now with testSquare by placing a breakpoint inside of the LinkedIntList.square (located in intlist/src) method and then running the program in debug mode.
When the debugger stops at the specified breakpoint, the Run tool window will turn into the Debug tool window. Here, you can see the paused state of the program. At the top of the Debug tool window are small icons for controlling the debugger, including the two most common operations to Step over and Step into the next statement. This is similar to how the jGRASP debugger works.
We can visualize the debugger output by tapping on the Java Visualizer button at the top of the Debug tool window. This will draw a box-and-pointer diagram representing the paused program state. Step through the execution of the program, or use the green continue icon on the left side of the Debug tool window.
Now, we have all the tools we need to work on LinkedIntList.