[14:47:03] duesen_: I have questions (as always) [14:47:23] We had quite some discussion around the MediaWikiUnitTestCase in core earlier internally [14:47:42] If you or someone on cor platform has 10 mins to talk about it that would be great! [15:55:00] addshore: I think Tim has oppinions, but he's asleep :) [15:55:17] :D [15:55:19] I have a meeting in 5 minutes, and some chores after... [15:55:31] I'm interested in the discussion though [15:55:50] ack! [15:55:58] main question is about clarifying the doc block [15:56:05] "do not access global functions, variables, services or a storage backend." [15:56:18] Yea, it'S a lie [15:56:19] "access" and also "global services" etc :P [15:56:22] :P [15:56:26] I mean, it would be great if it was true, but it isn't. [15:57:25] I like Krinkle's take: a Unit test is anything that fully controls the state of the thing under test. No matter how big the thing is, or whether it has global state. [15:58:38] an integration test only controls state directly related to the function under test, and makes (more or less) assumptions about the rest. [15:59:13] For MediaWiki, integration tests require a mediawiki installation, and a fully initialiezd runtime. [16:08:21] yup [16:09:00] the bulk of the question that came up, is, is it okay to extend MediaWikiUnitTestCase and set globals for use within the test that is being carried out [16:09:13] and assume that MediaWikiUnitTestCase does all the cleanup needed for that [16:09:38] Also, can tests / should tests extending it be allowed to interacte with things such as ExtensionRegistry [16:09:50] or is all of that really just a recipie for disaster down the line and not what the test base was intended for [20:37:36] duesen_: ^^ thoughts (unless it is too late) :D [20:38:30] I think basically we would love a little path to the phpdoc of the class being a bit more specifica about what is okay and what is not okay with the intentions of the class, as right now we are wmd are interpreting the doc in different ways. [20:38:37] ^^ of anyone else from core plat! [20:56:19] addshore: ask amir, he created it ;) [20:56:56] All the questions you asked are good questions with no easy answer. It would eb good to have a place to have this discussion in full. [20:57:19] wikitech-l? and RFC? A wiki page? something :) [20:57:46] Also, pull in COde Health. Ask JR- [20:58:31] Amir1: ^^ :P I didnt realize you wrote the whole thing! :P [20:58:47] git blame gave me a very different image [21:15:47] addshore: let me read [21:18:59] addshore: I think you should talk to kostajh about it. My idea is to keep the code separated from the global state as much as possible [21:25:17] addshore: i would recommend against subclassing the unit test case [21:25:25] :D [21:25:51] Also, what it says about not being able to access globals is true if you run the unit tests with vendor/bin/phpunit [21:26:16] is the intention that classes that subclass it should ideally be runable with phpunit directly? [21:26:28] Thats what my vision of the intention behind the class was [21:26:36] If you want to tag me in a patch I’d be happy to comment on specifics [21:27:19] that would be https://github.com/wikimedia/mediawiki-extensions-TwoColConflict/blob/master/tests/phpunit/unit/TwoColConflictContextTest.php [21:27:26] addshore: sorry re: subclassing I meant specifically about the case you described above for setting and cleaning up globals [21:27:29] which touches globals and what you could also deem to be global services [21:27:57] I'm not working on this code, but it came up earlier and there was quite a discussiuon about this base class and its intentions [21:28:29] Where was the discussion? [21:29:27] Basically I don’t think the word “global” should appear when you are writing tests which extend the unit test case [21:30:58] addshore: it’s late and I’m signing off, but can continue the discussion another time, let me know! \o [22:19:57] yes also let, im going to bed :D [22:20:09] I may come back in the morning!