I would like to write a junit test for my Checkstyle extension. Can someone show me how to do it? I know there is a project in github called JUnit-Checkstyle-Test-Wrapper. However, I don't see how using this tool would help me get to my extension and verify its values.
thanks.
Probably the best reference for how to test your checkstyle extension (I assume you've added a checker) is to look at the checkstyle source code, and just copy & change one of the existing tests. For example, here is the test for HeaderCheck. This is probably the best way to start. Remember you can actually extend the Checkstyle test classes.
take a look at a lot of examples for custom Checkstyle checks and UTs for them https://github.com/sevntu-checkstyle/sevntu.checkstyle/tree/master/sevntu-checks
Related
Can someone tell me please: how to take a screenshot when test method fails (jUnit 5). I have a base test class with BeforeEach and AfterEach methods. Any other classes with #Test methods extends base class.
Well, it is possible to write java code that takes screenshots, see here for example.
But I am very much wondering about the real problem you are trying to solve this way. I am not sure if you figured that yet, but the main intention of JUnit is to provide you a framework that runs your tests in various environments.
Of course it is nice that you can run JUnit within your IDE, and maybe you would find it helpful to get a screenshot. But: "normally" unit tests also run during nightly builds and such - in environments where "taking a screenshot" might not make any sense!
Beyond that: screenshorts are an extremely ineffective way of collecting information! When you have a fail, you should be locking for textual log files, html/xml reports, whatever. You want that failing tests generate information that can be easily digested.
So, the real answer here is: step back from what you are doing right now, and re-consider non-screenshot solutions to the problem you actually want to solve!
You don't need to take screen shots for JUnit test failes/passes, rather the recommended way is to generate various reports (Tests Passed/Failed Report, Code coverage Report, Code complexity Report etc..) automatically using the below tools/plugins.
You can use Cobertura maven plugin or Sonarqube code quality tool so that these will automatically generate the reports for you.
You can look here for Cobertura-maven-plugin and here for Sonarqube for more details.
You need to integrate these tools with your CI (Continuous Integration) environments and ensure that if the code is NOT passing certain quality (in terms of tests coverage, code complexity, etc..) then the project build (war/ear) should fail automatically.
I'm using Hudson continuous integration tool. I also run the checkstyle plugin as part of the build, and publish the checkstyle analysis result in Hudson. How could I make the build fail if I encounter a checkstyle error/warning?
I tried to add a rule to the Parsing Rules File, but this doesn't seem to work.
Thank you in advance.
It could be solved with Checkstyle plugin for Hudson/Jenkins. You can read about it here.
gradle-estilo-plugin provides the ability to fail the build if checkstyle task encountered errors. It also lets you specify rules in your build.gradle file instead of having separate files like checkstyle.xml, suppressions.xml, impor-control.xml etc.
You can instruct the estilo plugin to fail the build as:
estilo {
ignoreWarnings false
}
On a side note, I must point out that I wrote this plugin myself and I use it extensively in all of my projects.
We have a group of developers moving from C++ to C# and WinRT. We used D'Oxygen as part of our C++ developer builds, and I'd like to continue to have document generation as part of the developer build in C#/WinRT.
It's easy to turn on XML Doc generation, and I believe that will provide warnings for malformed tags, but without actual HTML output, I think our developers will be missing valuable feedback.
Looks like NDoc is now defunct, and I took a quick look at Sandcastle, but found it rather complex. Ideally, I'm looking for something that doesn't unduly burden developers, or require them to remember extra steps as they edit, build, test, and commit. In other words, the best solution would be something that "just happens", like a post-build step, and doesn't add significantly to each developer's build time.
If anyone has had some experience doing this in C#/WinRT, I'd sure like some advice.
Thanks in advance!
Get Sandcastle Help File Builder.
Create a help project for your library in the Visual Studio solution.
Remove Build check mark from Debug solution configuration to build the documentation project only in Release configurations, since Debug is most often used during development. For release build testing or performance testing you can either create another solution configuration or simply switch the option back and forth.
Build the documentation once
Include the documentation file in the solution so it shows up in the Pending Changes window when the file changes.
Kindly ask your developers to build with the release configuration that updates the documentation before check-in or use any other policy to require updating the documentation.
I don't think it makes sense to build the documentation all the time, but it helps to make it easy to do so that when you actually need an updated version - you can build it really quickly.
You can also make sure to use FXCop or StyleCop (forgot which) and configure it to treat missing XML documentation warnings as errors - at least in release builds. Doing it for debug configurations might slow down development and make changes difficult since developers often want to try things out before committing to a final implementation worth documenting.
EDIT*
Sandcastle provides various output formats as shown in the project properties:
I would like to mention ForgeDoc (of which I'm the developer), it could be what you are looking for. It is designed to be fast and simple, and it generates proper MSDN-like HTML output. It also has a command-line interface so you can just call it from a post-build event command in Visual Studio.
I think you should give it a try, as I would really like to hear about your thoughts.
I'm in the middle of setting up PMD as a tool in our team to support us writing better code. Basically I'm building Ant scripts and try to set up some rules for everyone to use.
But right now I hit this problem:
When I write JUnit tests I don't want to use the same rules I apply on our main source code. I don't care that much about String rules (like string dupliates or weird instantiations) in the junit tests.
My questions is:
Is that a fault on my side and should I start writing better JUnit tests?
Should I provide a 2nd set of rules that disables some of the string/design/finalizers rules?
The second option - I don't run PMD against my tests at all. I could and PMD provides some JUnit specific rules. I would definitely use a separate ruleset against the test code though. I expect more String literals and some thing specified instead of using conditionals/loops. After all, I don't want to duplicate the code I am trying to test.
Two things. Why are you trying to set up rules why not using the existing rules? (Special requirements?). And second yes of course Unit tests should have a good quality as well. Your Unit test test you production code so shouldn't they have at least the same quality as your production code?
I'm looking for some way to replace patterns in files with values, during build time.
E.g. a configuration file may look the same except that different machines requires different hostnames in some setting. In that case i want to have a template file, where hostname is replaced with ##hostname##
Then when building, I want to create separate versions of the file with the patter replaced with the correct value for each environment.
In ant you could use "replace", is there something similar in maven2? I know that I can run ant form maven, but if theres a maven plugin doing it, I'd prefer that one.
I found http://code.google.com/p/maven-replacer-plugin/
but it's very new...
Suggestions?
Thanks!
The resource plugin is what does filtering in Maven. IIRC it supports the ant syntax as well as the ${foo} maven syntax.
keep up with the maven-replacer-plugin, the project is still alive and well
Maven's resource filtering might help you out.
Why don't you use the Maven-ant plug-in?