4

I'm having this logic to check a java file content and verify that it has a comment, which says who is the author(not necessarily the creator) of that file - special requirement of the project.

I wrote a unit test using Junit to check the logic and it works fine.

And I want all the .java files adhere to that standard and make the build fail if at least one of them does not comply to that.

So far I have my Junit test method to do the following,

  1. Read all the .java file contents in the application
  2. For each content check if it contains the comment which has the standard format
  3. Fail the test case if at least one of them with no comment with such a format (so that eventually the build will fail)

Is that a correct approach? It will serve the purpose but is it a good practice to use Junit test to do some verification work.?

If not, what kind of approach should I use to analyze(using my logic - I have a Analyzer.java file with the logic) all the files in the build time and have the build be success iff all files comply too the required standard.

EDIT : Code comment check is only one verification. There are several checks that need to be done. (ex : variable names should end with a given suffix, patterns to use some internal libraries .. etc) All the scenarios are handled in that logic (Analyzer.java). Just need to check all the java file contents and use that logic to verify them.

It's safe to say like I have a java library and when invoked a method that accept a file name , check(fileName) , it will analyze the file and return true if it pass some invisible logic. And if it returns false build should be failed. Since I need to fail the build if something is not right I'm using it in a jUnit test to check all my .java files in the code base.

If this can be done by a static code analyzing tool (but needs to use the logic I have) it is also acceptable. But I don't have an idea whether this kind of custom verification supports by the existing static code analyzers.

Maciej Kowalski
  • 25,605
  • 12
  • 54
  • 63
prime
  • 14,464
  • 14
  • 99
  • 131
  • yeah. any idea about the above scenario ? how it can be done. I feel I'm not doing it correct now with tests. just some sample resource may be. – prime Jan 24 '17 at 19:49

3 Answers3

2

Is that approach I'm using correct ? ... is it a good practice to use junit test to do some verification work

No. Unit testing is for checking the integrity of a code unit, ensuring the unit's behavior works properly. You should not be checking comments/documentation in unit tests.

Since I need to fail the build if something is not right..

You need to add more steps to your build process, more specifically a static analysis step.

Unit testing is considered a build step, along with compilation, execution and deployment. Your project requires an extra step, which brings me to the following...

You could use a build tool, such as Apache Ant, to add steps to your project's build. Although static analysis doesn't come bundled (this is simply a build automation tool), it does allow you to ensure that the build fails of a custom build step fails.

With that said, you could add a step that triggers a static analysis program. This page contains an example of using Ant to create multiple build steps, including static code analysis and bug checking. You could even create your own analyzer to use.

For more information about build tools & automation:

StackOverflow: What is a Build Tool?

Wiki: Software Build > Build Tools

Wiki: Build Automation

Community
  • 1
  • 1
Vince
  • 14,470
  • 7
  • 39
  • 84
  • great. any way to do this using maven build ? – prime Jan 25 '17 at 11:25
  • @prime Yes, Maven has a Build Lifecycle which allows you to scale up phases of the cycle via [plugins](https://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html#Plugins). – Vince Jan 25 '17 at 20:03
1

You can use Checkstyle for that. Build can be failed. Check comments. It is called static code analysis.

To define the format for an author tag or a version tag, set property authorFormat or versionFormat respectively to a regular expression.

Grzegorz Górkiewicz
  • 4,496
  • 4
  • 22
  • 38
  • Hi thanks. Btw there are several other requirements to check also. Not only the comment which specify the author. Some specific code analysis/parsing needs to be done. Can they be also achieved by this. Anyway I need to use my custom Analyzer logic in this. – prime Jan 24 '17 at 19:34
  • Not only comments, of course. [You can avoid tabs for example](http://checkstyle.sourceforge.net/config_whitespace.html#FileTabCharact). [Rules for Google's Java code](https://github.com/checkstyle/checkstyle/blob/master/src/main/resources/google_checks.xml). – Grzegorz Górkiewicz Jan 24 '17 at 19:40
  • great. But it seems no way to use a custom analyzer logic (well it is written in java) – prime Jan 24 '17 at 19:44
1

If that would be my project then i would not be placing this kind of verifications in the standard src/test/java and run as part of the test suite of the application. Unit tests suite should be testing production logic and not doing 'coding style' checks.

A place for this kind of verification would be for example on a pre-commit to git repository. And all the scripts checking this (or style-checking tools) would be invoked in that place.

You can put everything in one place, but as far as i can see the, the separation of concerns in all the areas of the software development are the leading trend for quite a while.. and there is a good epoint to that.

Maciej Kowalski
  • 25,605
  • 12
  • 54
  • 63
  • good approach. Yet it's the requirement. Build should be failed if files violate the standard. – prime Jan 24 '17 at 19:35
  • Well i believe and try to follow the separation of concerns or SRP in all the possible areas of development. If you have to, you have to but i fought many times with requirements from Senior Devs .. and i succeeded. So maybe you can give it a shot, you have a good purpose ;) – Maciej Kowalski Jan 24 '17 at 19:38
  • good. yet if we can fail the build then most of the mistakes can be avoided at the first place in dev time also. yet have pros and cons. – prime Jan 24 '17 at 19:42
  • An obvious con, would be freezing the entire project until all the comments are in place, because you could not build otherwise.. With pre-commit, developers would learn anyway because they would not be able to commit their new stuff.. and the legacy comments could be filled in gradually with time – Maciej Kowalski Jan 24 '17 at 19:49