Closed roperto closed 7 years ago
This is a pretty major issue for us... we run these tests automatically on all our clients codebases.
It might be worthwhile for the Turnitin team to implement travis-ci checks directly within github to help prevent this stuff from happening. There's a good post on how to add support here: https://moodle.org/mod/forum/discuss.php?d=323384
but it's really just copying a .travis.yml file, adjusting it as needed and going to travis-ci.org and switching it on.
A quick note: https://github.com/turnitin/moodle-plagiarism_turnitin/pull/188 (created by one of our Moodle developers, Travis Noll) addresses this specific issue as well. Let this be another vote to implement travis-ci and Behat tests in this plugin.
We're also seeing this on Moodle 3.0:
1) tool_uploadcourse_course_testcase::test_reset Unexpected debugging() call detected. Debugging: Exception encountered in event observer 'plagiarism_plugin_turnitin::course_reset': Trying to get property of non-object
It's still an issue in Moodle 3.2 with failing unit tests (same as the Moodle 3.0 unit test failing above).
We plan to have this issue fixed in the next release.
Moodle 3.2 support is another issue however - we don't support it in the latest release but we will be supporting 3.2 once we've fully tested it - that too will require a release.
Hi @roperto ,
This has been fixed in the latest release v2017012501
@dwinn - did you fix the course reset failure shown above too? - I am still seeing this on the latest build.
Hi @danmarsden,
You are correct, I have just ran the tests tool_uploadcourse_course_testcase and I am still getting an error. The error is different to the one posted here however. Part of the stack trace:
Debugging: Exception encountered in event observer 'plagiarism_plugin_turnitin::course_reset': Undefined index: reset_assign_submissions
We will get this fixed.
Has anyone else run into this issue?
When I run core Moodle 31 PHPUnit tests, one of them fails if I have this plugin installed.
I've isolated the problem in the lib, where it finds the supported modules based on the file (classes/modules) system then tries to fetch the ID in the database.
Because it cannot find the module in the DB (returns false), if fails when trying go get the $module->id.
I wrote a test reproducing the behaviour and a proposed solution; however, someone who has better understanding of this plugin could propose a better solution.
Cheers,
Daniel