Got closer with the temptables stuff, it turns out the create_database function isn't called at all, instead PDO itself handles creating the database based on the DSN. Still not sure where to create the sqlite3_pdo_moodle_temptables object though. Whatever I do it seems to be null by the time it gets used.
David Scotson
Posts made by David Scotson
I ran the tests and recorded code coverage stats and it's looking pretty good, pretty much complete coverage. The things skipped are the usual exceptions and error states that can be quite tricky to test.
And in the process I noticed one test that doesn't look like it's being run because it doesn't have the right name (tests starting with "test" get picked up automatically, someone has typed sql_sql_etc. rather than test_sql_etc.).
And as another bonus, because of the code coverage report I think I may also have figured out why the moodle_temptables stuff wasn't working. None of the DB setup calls were run during the tests. They get called as part of the CLI init script instead, so no wonder my changes weren't being picked up. I'll try deleting the DB and starting from scratch and see if I can get it working that way.
And in the process I noticed one test that doesn't look like it's being run because it doesn't have the right name (tests starting with "test" get picked up automatically, someone has typed sql_sql_etc. rather than test_sql_etc.).
And as another bonus, because of the code coverage report I think I may also have figured out why the moodle_temptables stuff wasn't working. None of the DB setup calls were run during the tests. They get called as part of the CLI init script instead, so no wonder my changes weren't being picked up. I'll try deleting the DB and starting from scratch and see if I can get it working that way.
I think I've got it all mostly working. It was all just a series of little odd things missing, no fundamental barrier as far as I can tell.
Currently I'm trying to get temptables working. It seems just to be an empty object that stores some links to objects, but I'm not sure when and where it should be created. If anyone understands the moodle_temptables family of classes any hints would be welcome.
And I've got a weird one where the test passes if I run it by itself, but consistently fails when I run it as part of the full test suite. Which shouldn't really happen.
But overall I think I've got one failure and two errors in the Database tests, and about 15 or so errors in the full test suit of 1350 so looking in pretty good shape. (Normally, the non-database tests wouldn't give you much faith that the database bits were working, but Moodle's test suite is more like functional tests than unit tests, so I think the database layer is getting a reasonable workout as a side-effect of these other tests. I'm going to run some code coverage tests to check that assumption once I get the full suit running to completion).
Edit: after telling it to skip the mod_data tests it completed:
Tests: 1361, Assertions: 13139, Failures: 3, Errors: 13, Incomplete: 6, Skipped: 1.
I've also got six tests marked as incomplete, as they seem to be testing stuff that SQLite doesn't do, like throwing errors if you put an string in an int column, but that aren't actually required by Moodle (since any code that did that wouldn't work on the other DBs) and a bunch more like that commented out as they were just one assertion in a longer test.
So I'll be working through the rest of these, but if you've got a specific use for SQLite, I'd say it's worth at least investigating further at this stage.
Currently I'm trying to get temptables working. It seems just to be an empty object that stores some links to objects, but I'm not sure when and where it should be created. If anyone understands the moodle_temptables family of classes any hints would be welcome.
And I've got a weird one where the test passes if I run it by itself, but consistently fails when I run it as part of the full test suite. Which shouldn't really happen.
But overall I think I've got one failure and two errors in the Database tests, and about 15 or so errors in the full test suit of 1350 so looking in pretty good shape. (Normally, the non-database tests wouldn't give you much faith that the database bits were working, but Moodle's test suite is more like functional tests than unit tests, so I think the database layer is getting a reasonable workout as a side-effect of these other tests. I'm going to run some code coverage tests to check that assumption once I get the full suit running to completion).
Edit: after telling it to skip the mod_data tests it completed:
Tests: 1361, Assertions: 13139, Failures: 3, Errors: 13, Incomplete: 6, Skipped: 1.
I've also got six tests marked as incomplete, as they seem to be testing stuff that SQLite doesn't do, like throwing errors if you put an string in an int column, but that aren't actually required by Moodle (since any code that did that wouldn't work on the other DBs) and a bunch more like that commented out as they were just one assertion in a longer test.
So I'll be working through the rest of these, but if you've got a specific use for SQLite, I'd say it's worth at least investigating further at this stage.
I've not tried it yet, but I think this might suffer from the same problem as Danny's solution, where (because of the nature of CSS) it's easy to add layers on top of the existing theme, but much harder to outright replace things and start from an empty slate. So you'd have to worry about the admin side while desiging your front end,which is one of the main reasons this would be handy for Themers: it would reduce the amount of Moodle that they have to think about when making changes..
Can you set up user themes for only certain types of user? Perhaps via changing roles/capabilities?
This would mostly work, particularly if you were strict about enforcing that those administering a site used a separate account for administration and mostly logged in with a standard account when interacting in courses (or had two separate types of staff employed for these different roles).
But I'm really looking for something that can be pulled into core Moodle in the long term, as I think a clean seperation between admin and non-admin sections might improve the usability of both.
This would mostly work, particularly if you were strict about enforcing that those administering a site used a separate account for administration and mostly logged in with a standard account when interacting in courses (or had two separate types of staff employed for these different roles).
But I'm really looking for something that can be pulled into core Moodle in the long term, as I think a clean seperation between admin and non-admin sections might improve the usability of both.