[#4071] - Unit testing for plugins
- Closed
- 17 Dec 2015
- Medium
- Build: staging
- # 4071
- Diff
- wilsonge:plugintests
- Failure The Travis CI build failed Details
User tests: Successful: Unsuccessful:
OK So unit testing for plugins it turns out is easily doable
Now I need some ideas on how to test the email cloaking plugin (which currently is the bane of our lives) as of course it's designed not to be detectable my bots! Ideas anyone?
Currently tests are failing because I've added in JM's test examples and not bothered to add the correct expected results - just so people can experiment and look at what I've done.
jissues-bot
- | Labels |
Added:
?
?
|
||
| Description | ⇒ | <p>OK So unit testing for plugins it turns out is easily doable</p> <p>Now I need some ideas on how to test the email cloaking plugin (which currently is the bane of our lives) as of course it's designed not to be detectable my bots! Ideas anyone?</p> <p>Currently tests are failing because I've added in JM's test examples and not bothered to add the correct expected results - just so people can experiment and look at what I've done.</p> |
| Labels |
Added:
?
|
||
nicksavov
- | Labels |
Removed:
?
|
||
| Status | New | ⇒ | Pending |
| Category | ⇒ | Unit Tests |
I'd love to work on it more. But I'm really struggling for how to unit test a random number :(
javigomez
- | Labels |
Added:
?
|
||
| Labels |
Removed:
?
|
||
Can you update this PR to latest staging and solve the merge conflicts? Maybe we can work on this together in the near future and solve the test issues.
Hello @wilsonge
Thank you for your contribution.
The last comment here was on 3rd February. So the question is, Is this issue/pull request still valid?
If no reply is received within 4 weeks we will close this issue.
Thanks for understanding!
This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/4071.
Yes this is definitely still valid
Once that CLI specific thing comes out (which is a bad hack for the unit tests to always have a known value, changing the behavior of what's being tested ironically) there is no human testing involved in this one; it's all unit test changes (so ensure CI passes and code review).
So how do we deal with random numbers. I can't predict a random number as the unit test outcome :P
Assert the string contains a stretch of text around it, or come up with some kind of regex to assert that the string is built correctly with a number that's in the valid range defined by the randomizer. Altering the behavior of a method when you're testing it is probably worse than not testing the thing. Plus, this should only be testing what the plugin method does, not what the JHtml helper is doing too (but since it's all static, it can't be mocked, oh how I love the CMS environment sometimes...).
So you can try doing something like this I guess https://github.com/joomla/joomla-cms/blob/staging/tests/unit/suites/libraries/joomla/form/fields/JFormFieldCalendarTest.php#L262-L322
I don't know if I should laugh at how hysterical the notion of overriding JHtml calls with its API for testing is or cry because that's a necessity.
Hello @wilsonge
Thank you for your contribution.
The last comment here was on 23rd August. Are you planning to work on this any time soon? If not, please close and re-open when you plan to work on it.
If no reply is received within 4 weeks we will close this issue.
Thanks for understanding!
This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/4071.
| Status | Pending | ⇒ | Information Required |
| Labels | |||
| Status | Information Required | ⇒ | Closed |
| Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2015-12-17 11:11:52 |
| Closed_By | ⇒ | brianteeman | |
| Labels | |||
| Labels | |||
Closed due to lack of response for further information - it can always be reopened if that is provided
This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/4071.
Care to work on this some more that way we might be able to merge it in?