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

Initial test dedicated for the DefaultUnknownHandlerManager #205

Merged
merged 4 commits into from
Jan 29, 2018

Conversation

zalsaeed
Copy link
Contributor

@zalsaeed zalsaeed commented Jan 25, 2018

This is a very trivial test dedicated for the DefaultUnknownHandlerManager.

I'm doing some research that includes Apache Struts as an example. Most of the classes I'm interested in have sufficient tests. However, even though DefaultUnknownHandlerManager is tested through other tests created for other classes, those tests are not sufficient enough for my purpose. I'm pushing the given test for DefaultUnknownHandlerManager to confirm that it is acceptable by you.

@zalsaeed
Copy link
Contributor Author

I'm not seeing the relationship between what I have changed and the error given by Jenkins. Can someone explain please to fix it?

@coveralls
Copy link

coveralls commented Jan 26, 2018

Coverage Status

Coverage increased (+0.002%) to 46.611% when pulling 820d18d on zalsaeed:master into 9beb940 on apache:master.

@@ -0,0 +1,69 @@
package com.opensymphony.xwork2;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please copy and paste the LICENCE text from a neighbor test .java file to beginning of this file to pass Jenkins build :)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thanks, this is clear and fixed.

/**
* Partial test to the DefaultUnknownHandlerManager to understand the relationship between Manager and Handlers.
*
* @author Ziyad Alsaeed
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Apache doesn't accept author tag anymore. Instead see here if you're interested to contribute :)

/**
* Relationshsip when UnknownAction method is called.
*
* @author Ziyad Alsaeed
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(same here)

/**
* Relationship when UnknownActionMethod method called.
*
* @author Ziyad Alsaeed
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(same here)


ActionConfig.Builder actionConfigBuilder = new ActionConfig.Builder( "com", "someAction", "someClass");
ActionConfig actionConfig = actionConfigBuilder.build();
SomeUnknownHandler someUnknownHandler = new SomeUnknownHandler();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's a good practice to initialise such things in setUp method.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

you are right, fixed.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍

@lukaszlenart
Copy link
Member

Looks good to me, let @yasserzamani to pull the trigger :)

@yasserzamani
Copy link
Member

I see there is already a dedicated test for DefaultUnknownHandlerManager at /core/src/test/java/com/opensymphony/xwork2/util/UnknownHandlerManagerTest.java. I thought you may want to see it also and merge your ones into it if applicable or move the whole .java file beside it in same package. (I see that has tested handleUnknownMethod but missing handleUnknownAction which you have)

@zalsaeed
Copy link
Contributor Author

This is a tricky one. I'm not an expert in struts but this is slightly different from the DefaultUnknownHandlerManager I'm testing. I have ran all the available tests before and the lines of DefaultUnknownHandlerManager were not touched throughly. I can move the whole file under the util package, but wouldn't this be wrong? Because the class is within package /core/src/test/java/com/opensymphony/xwork2/.

* Partial test to the DefaultUnknownHandlerManager to understand the relationship between Manager and Handlers.
*
*/
public class DefaultUnknownHandlerManagerTest extends XWorkTestCase {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I tested extends TestCase and works. It seems you can downgrade to TestCase to save performance.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was following other test cases here. I will change it and push it if tests pass.

}

@Override
protected void tearDown() throws Exception {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It seems you can downgrade to TestCase to save performance and delete this.


String result = null;

for (int i = 0; i < 10 ; i++) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why 10 times? I'm just curious :)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is an arbitrary number. I wanted to see the difference this will make on what I'm developing.

@yasserzamani
Copy link
Member

This is a tricky one. I'm not an expert in struts but this is slightly different from the DefaultUnknownHandlerManager I'm testing. I have ran all the available tests before and the lines of DefaultUnknownHandlerManager were not touched throughly.

Hm.. but coverall says it's almost fully covered in last master build before this pr at here. I also reviewed that previous test case and saw it already has tested handleUnknownMethod. It seems you can add your new handleUnknownAction test to it as a new test method.

I can move the whole file under the util package, but wouldn't this be wrong? Because the class is within package /core/src/test/java/com/opensymphony/xwork2/.

Hm.. you're right. It seems it was there previously and moved here with no moved tests :)

@zalsaeed
Copy link
Contributor Author

I think wasn't clear when I said "were not touched thoroughly". What I meant is not related to if a line is touched or not (the general definition of test coverage). After all as I mentioned before, the class DefaultUnknownHandlerManager was tested through other tests cases that were dedicated to other classes. But that doesn't mean it was tested thoroughly. For any given source code there is the space of possible paths it could take and that space is hard to cover sometimes %100. Here I was trying to hit some of those missed paths. Please let me know if this is still not clear.

I also reviewed that previous test case and saw it already has tested handleUnknownMethod. It seems you can add your new handleUnknownAction test to it as a new test method.

Hm.. you're right. It seems it was there previously and moved here with no moved tests :)

But still there is no test class with the name DefaultUnknownHandlerManagerTest I still believe that it much clearer if you name each test class with the name of the class you are targeting. Nevertheless, I'm not %100 sure what coding style you follow. So, what do you think, should I keep the name of the class I pushed and maybe merge the test cases from UnknownHandlerManagerTest, do the opposite, or keep both classes since there exist two different classes (in the sources code DefaultUnknownHandlerManager and UnknownHandlerManager) and it is good to have a test class for each one?

@yasserzamani
Copy link
Member

No I also agree and your class name is good. And you're right, let keep both files as is and as @lukaszlenart
confirmed, I think I can merge it now while we discussed all possible things :)

Thanks 👍

@yasserzamani yasserzamani merged commit f34cf78 into apache:master Jan 29, 2018
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

Successfully merging this pull request may close these issues.

4 participants