Transcripted Summary
The test are now created, and they are running smoothly. Now, we want to upload these tests to a version control system so that everybody has access to run the test, update the test, and so on.
Before we do that, we need to make sure that the code we wrote is very nice, let's say — that it follows coding standards and best practices.
In order to check that the code is of high quality, we can use a feature that IntelliJ offers namely a Code Analyzer.
Using it can be done as follows. We can open the Project screen, and we can choose either a package like "taudemo" or a class. Let's say we are going to choose the package.
I'm going to right click once I've selected this package, and I will click the Analyze option, and then I will go to Inspect Code.
A new popup appears, where I'm asked, "What is the scope for the inspection of the code?"
So, where do I want to check for the code?
The 3 most important things to look at here are:
The Whole project, meaning you want to perform an analysis of every piece of code you have written in this project, excluding the external libraries;
You could check only the Uncommitted files; or
A specific Directory.
The Uncommitted files option is very, very useful.
So, whenever you are creating some new test or whenever you are changing some existing code, before you commit those changes to the repository you have the option to check only those files. Uncommitted files are, of course, the files that were changed from the time of the last commit and up to right now.
The Directory option, of course, is a directory and you can consider this to be also a package. So, in this screen, directory and package mean exactly the same.
What I will do now, for demo purposes, is to perform an inspection on the entire "taudemo" directory.
I am going to say, "okay I'm happy with the directory scope" and I will click OK.
You can see that now in the lower bar I have a new tab called Inspection Result.
Here is where the code inspection results will be stored.
By default, IntelliJ offers a wide range of checks that are being made on the code, but you can customize the results of the checks.
You can customize what you want the analyzer to check for in your code.
Maybe there are some items you don't want to check.
Maybe there are some items you want to enable, but by default they are disabled.
I will show you how to work with the settings after I show you what we have here.
On the left-hand side we have the types and categories of issues that were found in the code.
Here we have some Java issues, declaration redundancy type of issues, and two entries with 12 warnings and 2 warnings.
This means that the "Declaration access can be weaker" issue was found in 12 places.
- 5 times in the SeleniumTest class;
- 3 times in the WithAssertionTest class; and
- 4 times in the WithConfigurationTest class.
Regarding the "Declaration can have final modifier" issue this was found in two places namely, once in each of the classes mentioned here.
On the right side, you have some information regarding what this particular issue means.
You have the name which says, "Declaration can have final modifier inspection," and then you have an explanation of what this means, what this check refers to.
Above it, above this text you have two options.
You have the option to Suppress which means that whenever such an inspection will be made in the future this particular item here — a member, a class, or everything — will be omitted from this check.
So, the check will not be done for these items that you choose to Suppress.
For example, if we go to SeleniumTest where we have this issue, we can just say, Suppress for field.
And what happens here is that in the class…, let's jump to the class.
We have some change done by IntelliJ namely, a notation was added right before this field.
So, this field from now on will not go through this check again. I will just undue this because I don't want to have any suppression in my code.
I will go back to this screen and I will show you that the other option that you have for each of these issues is to apply the fix that basically resolves this issue.
So, if the issue was that a field was not final, by clicking the Make Final button, you can actually make it final.
The fix was applied to all these items that had this issue because the fix was made on the level of the issue.
So, I didn't go to a class and say Accept; or a on a method or on a field to say Accept the resolution that they're offering.
Instead I did that for all of the items in a particular issue category.
Let's see some other kind of issues that can be found by going to another package, let's say the java package and performing an inspection here.
Again, I will go to Analyze > Inspect code, and I will say I want to check the entire code in the Java folder.
After I do this, I will see again all kinds of categories of issues.
One of the largest categories where issues were found is Java. And here we have some subcategories, naming "Class structure", "Declaration redundancy", "Imports" and so on.
If we go Imports, we have Unused Imports — so in 16 places in the code we have unused imports.
We could expand all of these dropdowns to get exactly to the place where the issue was encountered.
For example, if I go to this entry, I will jump into the class where the issue is found and exactly to the line of code where this issue appears.
I could, again, apply this fix only for this entry if I go to the left-hand side of the Inspection Results screen.
And I can just click Delete unnecessary import. I could do this for the entire class if I wanted, so then 3 problems would be solved by clicking this Delete button.
Or I could just go to the entire category and I could say Delete unnecessary import.
In this case, if I do this then the entire category will disappear because this category, at this point, only had the "Unused import" type of issue inside it.
So, I can just delete the unnecessary imports and then as you can see the number of warnings has decreased from what we had initially, which was 190 to 175, and so on.
You could go through all of these issues and you can check what they represent.
For example, "Field can be local" or in "Declaration redundancy" we even have stuff like "Empty method."
There are some classes that I've created here that do not have any method implementations, only the method definitions.
I was about to fill them in later. Up until I do that the analyzer says, "look, you have these classes, you might need to check them because their empty."
NOTE
If you are not sure they're supposed to remain in the status they currently are in, you can just ignore this analysis results. Nobody is forcing you to actually fix what you see here, because some of them are guidelines more like, and some of them are absolutely mandatory.
You need to take each one of them case by case and analyze whether these are something that are worth looking into or not.
For example, here we have a "Redundant throws clause" which means a method declares that it's going to throw an exception but, in fact, it is not.
And you can see that by hovering the name of the exception and seeing that it is grayed out. And I get a message that the exception is never thrown. So, I can I just remove the unnecessary throwing of the exception and so on.
We have "Unused declarations" where variables or methods are created but they are never used. We have fields that can be final.
We also have a "Performance" issue meaning we called a method which applies to arrays with only one item, so with only one argument.
In this case IntelliJ suggests that this is a "Performance" issue, because we are supposed to call this method only if we have an array to pass to that method, and so on.
Take a look at all of these suggested improvements or results of your analysis and decide whether they need a fix or if it's only a temporary situation, or whether the check was not very relevant.
For example, I find that spelling, for me at least, is not something that I need.
I would like not to see any spelling checks in future code analysis; therefore, I can go to settings and just remove the spelling from the list of checks that are made.
I will go to File > Settings now, and we can search for "inspections" on the left had side in the search box, and then in the results screen, just click anywhere for the gray area to go away.
Here you can see all of the checks that can be made by IntelliJ.
Some of them are available by default. As you can see, some of them are already checked, some of them are not.
If you want to enable or disable some of them, you can just go to the one you're interested in and you can just disable it from there.
For example, if I go to "spelling," I have Spelling > Typo.
On the right side you have some options for each of these categories, — these are specific options for each category.
In my case I just want to remove the spelling altogether. So, I will just uncheck the "Spelling."
There was also some other checks regarding "Weaker" declaration access, and I don't want to have these anymore for top-level classes, packages, and JUnit tests.
Instead of suppressing these checks, as I could have done from the results screen, I just went to the settings and I unchecked certain options regarding this check. I will just hit Apply and OK.
If we run the same check again, let's say on the Java folder; if we go again to Analyze > Inspect Code, we will see that now we won't have any more spelling checks, so the number of warnings is much smaller.
In this case we only have 36 warnings at this time, because I disabled certain checks that we had initially.
This is all when it comes analysis.
Just try it out, take a look at what checks have been run.
Add some checks if you would like or enable them, remove those that you find not meaningful and just run your checks. Then analyze whether you need to update something, or you can just leave the code as it is and just ignore those analysis results.
