{"id":96,"date":"2024-07-30T06:49:54","date_gmt":"2024-07-30T06:49:54","guid":{"rendered":"https:\/\/libraryresources.nse.org.ng\/computersciencetwo\/chapter\/using-gradle-projects-and-testng-with-vscode\/"},"modified":"2026-03-16T14:29:36","modified_gmt":"2026-03-16T14:29:36","slug":"using-gradle-projects-and-testng-with-vscode","status":"publish","type":"chapter","link":"https:\/\/libraryresources.nse.org.ng\/computersciencetwo\/chapter\/using-gradle-projects-and-testng-with-vscode\/","title":{"raw":"Using Gradle Projects and TestNG with VSCode","rendered":"Using Gradle Projects and TestNG with VSCode"},"content":{"raw":"
\n

Lecture: Running Gradle Projects<\/a><\/p>\n

Lecture: Using TestNG with VSCode<\/a><\/p>\n\n

<\/a>Intro to Gradle<\/h3>\n

This semester, we're using a build tool called Gradle. Gradle allows you to specify exactly how your project should be built - which version of Java to use, which source files to include, which testing framework to use, etc. If you're curious, you can see the build file in app\/build.gradle<\/em>. Don't modify the file, though!<\/p>\n\n

<\/a>Using Gradle Tasks<\/h3>\n

There are a few ways to run a Gradle project in VS Code. If your project has a main method, you should see \"Run\" appear above the main method. However, not all of your projects will have a main method.<\/p>\n

Gradle has several \"tasks\" built in. We'll use the following tasks:<\/p>\n

build<\/em> - compiles your project and runs the tests<\/p>\n

build -x test<\/em> - compiles your project without running tests<\/p>\n

run<\/em> - runs the project, if it has a main method<\/p>\n

test<\/em> - runs the tests<\/p>\n

clean <\/em>- removes all the temporary build files (like .class files)<\/p>\n

You can run tasks individually or multiple at a time.<\/p>\n\n

<\/a>Build<\/h4>\n

To run a Gradle task in VS Code, click on the elephant icon on the left side. At the top next to GRADLE PROJECTS, the first icon will let you run a task.<\/p>\n

\"image\"<\/p>\n

To compile your project, type build -x test<\/em> in the box that pops up when you click the Run a Gradle Build<\/em> icon. Press Enter to run the command.<\/p>\n

\"image\"<\/p>\n

This will compile your code, but not test it. The output will appear in the terminal.<\/p>\n

\"image\"<\/p>\n

If you have errors, the errors will appear in the terminal as well.<\/p>\n\n

<\/a>Run<\/h4>\n

If your project has a main method, you can run it by entering run<\/em> in the Gradle build<\/em> box. If you haven't previously built your project, it will first build and then run.<\/p>\n

\"image\"<\/p>\n

The output will appear in the terminal.<\/p>\n

\"image\"<\/p>\n\n

<\/a>Debug<\/h4>\n

To debug the main method, it's easiest to run the task using the GUI.<\/p>\n

Expand the Tasks<\/em> folder, then expand application.<\/em> Hover over the run<\/em> task and two icons should appear. The first has a bug with a play button - that's your debugger.<\/p>\n

Note you could run the run<\/em> task by clicking the play button next to run.<\/em><\/p>\n

Make sure you set breakpoints by clicking on the line number where you want to break. A red dot should appear.<\/p>\n\n

<\/a>\"image\"<\/strong><\/h2>\n

Using the debugger is covered in a different document.<\/p>\n\n

<\/a>Test<\/h4>\n

To run your tests, enter clean test.<\/em><\/p>\n

Running clean before testing ensures that the test output appears.<\/p>\n

\"image\"<\/p>\n

The output will appear in the terminal. VS Code offers several ways to run Gradle tests; those other options will be covered in a different document.<\/p>\n

\"image\"<\/p>\n\n

<\/a>Clean<\/h4>\n

Cleaning the project removes all of the temporary files and folders that are created during the build process. You can clean a project to force it to rebuild, which can sometimes fix weird errors. You may also want to clean your project before you commit your files to GitHub so you don't push a bunch of files you don't need and it's easier to see what needs to be committed.<\/p>\n

To clean, enter clean<\/em> in the Gradle Build <\/em>text box.<\/p>\n

\"image\"<\/p>\n

If all goes well, you'll get a pretty simple output.<\/p>\n

\"image\"<\/p>\n\n

<\/a>Introduction To Running TestNG Tests with VSCode and Gradle<\/h3>\n

VS Code has a pretty nifty testing interface. If you just want to run all of the tests, you can use the test<\/em> task. But you can also run specific tests and debug tests by using the test interface.<\/p>\n\n

<\/a>Test Gradle Task<\/h4>\n

To run your tests, enter clean test.<\/em><\/p>\n

Running clean before testing ensures that the test output appears.<\/p>\n

\"image\"<\/p>\n

The output will appear in the terminal. VS Code offers several ways to run Gradle tests; those other options will be covered in a different document.<\/p>\n

\"image\"<\/p>\n\n

<\/a>VS Code Testing View<\/h4>\n

To open the Testing View, click on the beaker icon on the left side. Expand the menus until you see your test files. You can click the arrow by the test file to see a list of tests in each file.<\/p>\n

\"image\"<\/p>\n\n

<\/a>Run All Tests or Some Tests<\/h4>\n

If you hover over each line, you'll see three icons: Run, Debug, and Go to Test.<\/p>\n

Run and Debug do exactly as they say - run or debug whatever you're hovering over. Go to Test will take you to the implementation in the test file.<\/p>\n

\"image\"<\/p>\n

In this scenario, I have two test classes - LabTest and MainTest. If I run app<\/em>, then all of the test classes' tests will run. if I run MainTest<\/em>, then all of the test methods inside MainTest<\/em> will run. If I run a specific method, then only that method will be run.<\/p>\n

For example, if I click on Run<\/em> next to testGetGreeting, <\/em>the only method that runs is testGetGreeting<\/em>. Note there isn't a checkmark or an X next to LabTest <\/em>or testGetPlanet<\/em>; those tests didn't run!<\/p>\n

\"image\"<\/p>\n

If the test passed, you'll see a green check mark next to it. If the test failed (or any test inside the test class failed), you'll see a red X next to it. In the picture below, all of the LabTest <\/em>methods passed. In MainTest<\/em>, one test passed and one test failed. Because of the failing test, it shows that MainTest<\/em> has failed tests, package lab<\/em> has failed tests, and the entire project app<\/em> has failed tests.<\/p>\n

\"image\"<\/p>\n\n

<\/a>Failing Tests<\/h4>\n

If a test fails, you'll get an error pop up at the line that failed. If you click on the name of the test that failed in the Test Result panel (at the bottom), you can read the error message. The first line of the error message tells you what was expected and what the test actually got.<\/p>\n

\"image\"<\/p>\n

In this case, it may be easier to execute the Gradle clean test<\/em> tasks so you can clearly read the error messages:<\/p>\n

\"image\"<\/p>\n\n

<\/h2>\n

<\/a>Debugging Tests<\/h4>\n

To debug, you first need to set a breakpoint, then click \"Debug test\". You can use the handy \"Go to Test\" to take you right to the method where you want to set your breakpoint!<\/p>\n

\"image\"<\/p>\n

Set a breakpoint by clicking just to the left of the line number.<\/p>\n

\"image\"<\/p>\n

That's where the program will stop so you can inspect the variable values<\/p>\n

\"image\"<\/p>\n

<\/p>\n\n<\/div>","rendered":"

\n

Lecture: Running Gradle Projects<\/a><\/p>\n

Lecture: Using TestNG with VSCode<\/a><\/p>\n

<\/a>Intro to Gradle<\/h3>\n

This semester, we’re using a build tool called Gradle. Gradle allows you to specify exactly how your project should be built – which version of Java to use, which source files to include, which testing framework to use, etc. If you’re curious, you can see the build file in app\/build.gradle<\/em>. Don’t modify the file, though!<\/p>\n

<\/a>Using Gradle Tasks<\/h3>\n

There are a few ways to run a Gradle project in VS Code. If your project has a main method, you should see “Run” appear above the main method. However, not all of your projects will have a main method.<\/p>\n

Gradle has several “tasks” built in. We’ll use the following tasks:<\/p>\n

build<\/em> – compiles your project and runs the tests<\/p>\n

build -x test<\/em> – compiles your project without running tests<\/p>\n

run<\/em> – runs the project, if it has a main method<\/p>\n

test<\/em> – runs the tests<\/p>\n

clean <\/em>– removes all the temporary build files (like .class files)<\/p>\n

You can run tasks individually or multiple at a time.<\/p>\n

<\/a>Build<\/h4>\n

To run a Gradle task in VS Code, click on the elephant icon on the left side. At the top next to GRADLE PROJECTS, the first icon will let you run a task.<\/p>\n

\"image\"<\/p>\n

To compile your project, type build -x test<\/em> in the box that pops up when you click the Run a Gradle Build<\/em> icon. Press Enter to run the command.<\/p>\n

\"image\"<\/p>\n

This will compile your code, but not test it. The output will appear in the terminal.<\/p>\n

\"image\"<\/p>\n

If you have errors, the errors will appear in the terminal as well.<\/p>\n

<\/a>Run<\/h4>\n

If your project has a main method, you can run it by entering run<\/em> in the Gradle build<\/em> box. If you haven’t previously built your project, it will first build and then run.<\/p>\n

\"image\"<\/p>\n

The output will appear in the terminal.<\/p>\n

\"image\"<\/p>\n

<\/a>Debug<\/h4>\n

To debug the main method, it’s easiest to run the task using the GUI.<\/p>\n

Expand the Tasks<\/em> folder, then expand application.<\/em> Hover over the run<\/em> task and two icons should appear. The first has a bug with a play button – that’s your debugger.<\/p>\n

Note you could run the run<\/em> task by clicking the play button next to run.<\/em><\/p>\n

Make sure you set breakpoints by clicking on the line number where you want to break. A red dot should appear.<\/p>\n

<\/a>\"image\"<\/strong><\/h2>\n

Using the debugger is covered in a different document.<\/p>\n

<\/a>Test<\/h4>\n

To run your tests, enter clean test.<\/em><\/p>\n

Running clean before testing ensures that the test output appears.<\/p>\n

\"image\"<\/p>\n

The output will appear in the terminal. VS Code offers several ways to run Gradle tests; those other options will be covered in a different document.<\/p>\n

\"image\"<\/p>\n

<\/a>Clean<\/h4>\n

Cleaning the project removes all of the temporary files and folders that are created during the build process. You can clean a project to force it to rebuild, which can sometimes fix weird errors. You may also want to clean your project before you commit your files to GitHub so you don’t push a bunch of files you don’t need and it’s easier to see what needs to be committed.<\/p>\n

To clean, enter clean<\/em> in the Gradle Build <\/em>text box.<\/p>\n

\"image\"<\/p>\n

If all goes well, you’ll get a pretty simple output.<\/p>\n

\"image\"<\/p>\n

<\/a>Introduction To Running TestNG Tests with VSCode and Gradle<\/h3>\n

VS Code has a pretty nifty testing interface. If you just want to run all of the tests, you can use the test<\/em> task. But you can also run specific tests and debug tests by using the test interface.<\/p>\n

<\/a>Test Gradle Task<\/h4>\n

To run your tests, enter clean test.<\/em><\/p>\n

Running clean before testing ensures that the test output appears.<\/p>\n

\"image\"<\/p>\n

The output will appear in the terminal. VS Code offers several ways to run Gradle tests; those other options will be covered in a different document.<\/p>\n

\"image\"<\/p>\n

<\/a>VS Code Testing View<\/h4>\n

To open the Testing View, click on the beaker icon on the left side. Expand the menus until you see your test files. You can click the arrow by the test file to see a list of tests in each file.<\/p>\n

\"image\"<\/p>\n

<\/a>Run All Tests or Some Tests<\/h4>\n

If you hover over each line, you’ll see three icons: Run, Debug, and Go to Test.<\/p>\n

Run and Debug do exactly as they say – run or debug whatever you’re hovering over. Go to Test will take you to the implementation in the test file.<\/p>\n

\"image\"<\/p>\n

In this scenario, I have two test classes – LabTest and MainTest. If I run app<\/em>, then all of the test classes’ tests will run. if I run MainTest<\/em>, then all of the test methods inside MainTest<\/em> will run. If I run a specific method, then only that method will be run.<\/p>\n

For example, if I click on Run<\/em> next to testGetGreeting, <\/em>the only method that runs is testGetGreeting<\/em>. Note there isn’t a checkmark or an X next to LabTest <\/em>or testGetPlanet<\/em>; those tests didn’t run!<\/p>\n

\"image\"<\/p>\n

If the test passed, you’ll see a green check mark next to it. If the test failed (or any test inside the test class failed), you’ll see a red X next to it. In the picture below, all of the LabTest <\/em>methods passed. In MainTest<\/em>, one test passed and one test failed. Because of the failing test, it shows that MainTest<\/em> has failed tests, package lab<\/em> has failed tests, and the entire project app<\/em> has failed tests.<\/p>\n

\"image\"<\/p>\n

<\/a>Failing Tests<\/h4>\n

If a test fails, you’ll get an error pop up at the line that failed. If you click on the name of the test that failed in the Test Result panel (at the bottom), you can read the error message. The first line of the error message tells you what was expected and what the test actually got.<\/p>\n

\"image\"<\/p>\n

In this case, it may be easier to execute the Gradle clean test<\/em> tasks so you can clearly read the error messages:<\/p>\n

\"image\"<\/p>\n

<\/h2>\n

<\/a>Debugging Tests<\/h4>\n

To debug, you first need to set a breakpoint, then click “Debug test”. You can use the handy “Go to Test” to take you right to the method where you want to set your breakpoint!<\/p>\n

\"image\"<\/p>\n

Set a breakpoint by clicking just to the left of the line number.<\/p>\n

\"image\"<\/p>\n

That’s where the program will stop so you can inspect the variable values<\/p>\n

\"image\"<\/p>\n

\n<\/div>\n","protected":false},"author":1,"menu_order":7,"template":"","meta":{"pb_show_title":"","pb_short_title":"","pb_subtitle":"","pb_authors":[],"pb_section_license":""},"chapter-type":[49],"contributor":[],"license":[],"class_list":["post-96","chapter","type-chapter","status-publish","hentry","chapter-type-numberless"],"part":18,"_links":{"self":[{"href":"https:\/\/libraryresources.nse.org.ng\/computersciencetwo\/wp-json\/pressbooks\/v2\/chapters\/96","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/libraryresources.nse.org.ng\/computersciencetwo\/wp-json\/pressbooks\/v2\/chapters"}],"about":[{"href":"https:\/\/libraryresources.nse.org.ng\/computersciencetwo\/wp-json\/wp\/v2\/types\/chapter"}],"author":[{"embeddable":true,"href":"https:\/\/libraryresources.nse.org.ng\/computersciencetwo\/wp-json\/wp\/v2\/users\/1"}],"version-history":[{"count":1,"href":"https:\/\/libraryresources.nse.org.ng\/computersciencetwo\/wp-json\/pressbooks\/v2\/chapters\/96\/revisions"}],"predecessor-version":[{"id":97,"href":"https:\/\/libraryresources.nse.org.ng\/computersciencetwo\/wp-json\/pressbooks\/v2\/chapters\/96\/revisions\/97"}],"part":[{"href":"https:\/\/libraryresources.nse.org.ng\/computersciencetwo\/wp-json\/pressbooks\/v2\/parts\/18"}],"metadata":[{"href":"https:\/\/libraryresources.nse.org.ng\/computersciencetwo\/wp-json\/pressbooks\/v2\/chapters\/96\/metadata\/"}],"wp:attachment":[{"href":"https:\/\/libraryresources.nse.org.ng\/computersciencetwo\/wp-json\/wp\/v2\/media?parent=96"}],"wp:term":[{"taxonomy":"chapter-type","embeddable":true,"href":"https:\/\/libraryresources.nse.org.ng\/computersciencetwo\/wp-json\/pressbooks\/v2\/chapter-type?post=96"},{"taxonomy":"contributor","embeddable":true,"href":"https:\/\/libraryresources.nse.org.ng\/computersciencetwo\/wp-json\/wp\/v2\/contributor?post=96"},{"taxonomy":"license","embeddable":true,"href":"https:\/\/libraryresources.nse.org.ng\/computersciencetwo\/wp-json\/wp\/v2\/license?post=96"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}