Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Test docgen code at a granular level #71

Open
magicDGS opened this issue Jun 7, 2017 · 4 comments
Open

Test docgen code at a granular level #71

magicDGS opened this issue Jun 7, 2017 · 4 comments

Comments

@magicDGS
Copy link
Contributor

magicDGS commented Jun 7, 2017

From @cmnbroad (#68 (comment)):

One high-level request is that we find a way to incrementally unit-test new functionality like this at a granular level. We currently only have coarse-grained, file-based integration tests, and I'd like to find a way to avoid proliferating a new set of test files with each new feature, in addition to changing many/all of the existing ones. @magicDGS any thoughts on how we can address that ?

@magicDGS
Copy link
Contributor Author

magicDGS commented Jun 7, 2017

Regarding this issue, I can tell you what it is the idea that I'm trying to implement in my own code:

  1. As in the current test implementation, I execute the javadoc to check that the whole doclet code is working and the templates are correct. In Barclay, I suggest to keep just the test for the default doclet/templates with some basic annotated classes, but remove the custom TestDoclet and associated templates.
  2. For concrete features that may or may not be included in the basic doclet generation test, I'm trying to use a mocking framework (e.g. Mockito) for ClassDoc. Like that, I can create DocWorkUnits without the need of executing the javadoc, and testing methods for docgen classes in a granular way.

Is this reasonable for you, @cmnbroad?

@cmnbroad
Copy link
Collaborator

cmnbroad commented Jun 8, 2017

Yes, a mocking framework is probably the right way to do this. Do you already have code that does this ? I'd like to solve this problem in Barclay before we add any more new features.

@magicDGS
Copy link
Contributor Author

magicDGS commented Jun 8, 2017

I was exploring this a bit in my toolkit and I implemented some minor tests as a proof-of-concept. If you like, I can add a couple of tests with Mockito and remove the TestDoclet code by the end of next week. Let me know if that fits you!

@cmnbroad
Copy link
Collaborator

@magicDGS That would be very useful. I wouldn't remove the TestDoclet test though, since we definitely need to test both default and custom doclet cases. At some point we may have enough mocked unit tests that we can remove one of them, but for now I think we should keep both. At least this will give us a start in the direction of less file bloat.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants