In a previous post, I showed how to start with Java and Maven in Gitpod.
This is the second post of this series, where I show a few interesting tools provided by the IDE. As I said in the previous post, this might be unrelated to Gitpod since we’re using the tools provided by Visual Studio Code and its Java extensions. However, I think the post still fits the Gitpod Java series.
Of course, this post assumes you have already followed the first post on Java and Gitpod, linked above.
We can enjoy several refactoring tools on Java projects. For example, in the “App.java”, let’s select the “Hello World!” string. We can access the available refactorings on the selected element via the context menu or by using “Ctrl+.” (Quick fix):
Let’s choose “Extract to method”:
The refactoring creates a new method returning the selected expression, and the original expression is replaced by the call to such a new method. We can use the text box to give the method a better name. (“Shift+Enter” will show a preview of the refactoring; however, if you’re used to Eclipse like me, the preview is not as visually appealing and informative as the one of Eclipse.)
Alternatively, we can accept the default name and then position the cursor on one of the “extracted” occurrences and choose F2 (“Rename symbol”) to rename the method and its references. A text box like the one above will appear to specify the name, for example, “getMessage”.
While on the method name, we can see other refactorings (“Inline” is the opposite of “Extract to method”) and actions:
Let’s choose “Change signature” and use the dialog to change a few details. For example, let’s make the method “public” (of course, that’s just an example: we could easily manually change “private” to “public”); if we haven’t renamed the method (e.g., to “getMessage”), we could do that right now with this dialog:
Let’s see what happens in case of a test failure. Now that we have a public method to call it by changing the test like that:
|
1 2 3 4 5 6 7 8 9 |
... public class AppTest { @Test public void shouldReturnTheExpectedMessage() { assertEquals("Hello", App.getMessage()); } } |
Let’s run the test (e.g., by using the green arrow of the code lens):
As expected, we get the test failure; in particular, we get some information about the failure both on the editor and with an additional pop-up.
Let’s fix the test with the right expected message and re-run it (again, by using the now red cross of the code lens); this time, it should succeed.
Now that we have removed the “assertTrue”, we have an unused import in the test case. We can fix that by manually removing the import, but it’s better to use a fix from the context menu in the “Problems” tab:
Alternatively, we can select the “Organize Imports” command using F1 and start typing or the corresponding shortcut “Shift+Alt+O”.
We can now enrich our project with a README.md file (exploiting the Markdown editor available in Visual Studio Code) and create a GitHub Actions workflow (again, using the YAML support, which knows about the GitHub Actions workflow schema).
For Markdown, we can also use the preview pane:
For the GitHub Actions YAML file, we can use the code completion:
That’s all for this second post. Stay tuned for the third one! 🙂
