Closed (fixed)
Project:
Drupal core
Version:
8.0.x-dev
Component:
simpletest.module
Priority:
Normal
Category:
Task
Assigned:
Unassigned
Issue tags:
Reporter:
Created:
26 Nov 2013 at 17:37 UTC
Updated:
13 Mar 2015 at 14:14 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #1
mile23Here's a patch.
Changes to TestBase:
- Added an instance method called t(), based on https://drupal.org/node/2079611 in order to remove a global dependency. Instead of calling t() we call $this->t(). This issue #1601146: Allow custom assertion messages using predefined placeholders talks about removing t() entirely or somehow changing the error reporting method, so obviously my version might already be obsolete.
- Not all instances of t() in the class can be replaced with $this->t(). Specifically within insertAssert() which is a static method, and so therefore can't call our instance method.
- Refactored database access out of assert(), into a new method called storeAssertion(). This allows us to capture the behavior of assert() in tests while avoiding the database access.
- require_once() at the top of the file. We can't use DRUPAL_ROOT without also including bootstrap.inc, which is the opposite of how unit testing it supposed to work. :-)
- Ignored testing of methods with lots of global dependencies.
- CRAP analysis: ~14000 to ~7000 after adding these tests. Still pretty high, but better.
Comment #2
dawehnerAwesome work!
I think this should be better like self::assert or static::assert
Are you sure that this change is needed?
Comment #3
mile23Done. :-)
Comment #5
mile233: 2144669_3_testbase_unit_test.patch queued for re-testing.
Comment #7
dawehner3: 2144669_3_testbase_unit_test.patch queued for re-testing.
Comment #8
nitesh sethia commentedComment #9
nitesh sethia commentedRerolling of the patch is done.. :)
Comment #12
nitesh sethia commented9: 2144669_9_testbase_unit_test.patch queued for re-testing.
Comment #14
nitesh sethia commentedPatch has been removed. I have removed the Php syntax issue.
Comment #15
nitesh sethia commentedComment #17
mile23It's a re-roll.
Simpletest tests pass fine locally, let's see what the testbot says.
Comment #18
mile23Yay testbot is happy, but we need to remove some references to t().
Comment #19
mile23Added beta evaluation to summary.
Comment #20
mile23Comment #21
daffie commentedI did a review and I have some problems with the patch:
Use @covers. Also for other functions
This is the provider for the function assert(). So shouldn't we call it providerAssert(). Also for other functions.
Document the return array. Also for other functions.
The only thing that is being tested is the function returns a value of FALSE.
Can we make two distinct mocks. The cloning results in mocks that have functions that they do not use. It is also a bit confusing for me.
Comment #22
mile237.
providerTestAssert()only gets used as a dataprovider fortestAssert().9 and 10. Both tests are pretty weak, so I updated them.
What I did:
setUp()away.testError()andtestCopyConfig().@covers.Comment #23
daffie commentedIf I read the best practices from #2057905: [policy, no patch] Discuss the standards for phpunit based tests, I get the idea that it is testAssert() and providerAssert(). I know that we have done a lot of providerTestAssert() constructions, so I thought I should mention it. But if I am wrong please let me know.
Comment #24
mile23Not wrong at all.
Comment #25
daffie commentedThank you for updating your patch. I have reviewed it again.
Can we move these functions to the top of the class. They are helper functions.
Data provider for testAssertIdentical
Can you explain this to me. The function error returns the assert function. And it is the assert function that you mock. So now you are testing if willReturn("$status:$group") is equal to "$status:$group". Can we concentrate on how the group is 'User notice' is treated differently.
Can we add a provider and test for null, 1, 2, 4 and 7. Also for randomObject and randomString. Sorry, should have mentioned it in the previous review. :-(
Just curious: why add these?
Comment #26
mile23Generally, we add things after existing code to minimize the reroll in other patches. It would make more sense to have them at the top, though.
We don't care what
assert()returns. The real test of whether we got the behavior around 'User notices is in this expectation:Combined with our data provider:
...we get an expectation that when
$groupis 'User notices,' we'll get the 'debug'$status, and 'exception' otherwise.copyConfig()takes two StorageInterface objects as arguments. We want to make sure the code distinguishes between them correctly. So we set up an expectation to that effect. If someone were editingcopyConfig(), it would be easy to mix them up, so we do what we can to help that person not make a mistake. That's the reason for making unit tests in the first place. :-)Comment #27
daffie commentedThank you for explaining the testError() function to me. I was wrong and somehow I looked cross eyed when I reviewed it.
For the testCopyConfig(): your explanation is also valid. I would not have added them. But I can also see your point of view.
It all looks good to me.
I have only one question and one nitpick left:
Should it not be: Contains \Drupal\Tests\simpletest\Unit\TestBaseTest.
Can we rewrite this to: $test_base = $this->getTestBaseForAssertionTests();
Comment #28
mile23For the
@fileblock: Good catch.For
$test_id... No, I want to be specific, because later on we say this:In fact,
getTestBaseForAssertionTests()shouldn't have a default value for$test_id.This patch:
getTestBaseForAssertionTests().testAssert()to compute the test id based on assertion status.Comment #29
daffie commentedIt all looks good to me.
All comments are in order.
The patch fixed the problem described in the issue summary.
The patch gets a RTBC from me.
Comment #32
daffie commentedBack to RTBC
Comment #35
daffie commentedBack to RTBC
Comment #36
alexpottThis is fine now that we don't have a unit test class that extends TestBase
Let's not add this test - it just ties us to the implementation making copy_config hard to change for no benefit.
In fact this is a general criticism of all of the tests - we are tying down internal implementation details making changing harder than necessary.
Comment #37
mile23Thanks for the review.
I will remove it, but being able to re-run this analysis is kind of the point of the test. This patch didn't need a reroll despite being a month old. The code it tests is basically set in stone, and any unintentional change to that code should set off alarms. Also, it's only the behavior of the testbot we're dealing with. :-)
Tying down *internal* details, but mocking *external* ones. This means you can just change the test. :-)
With a functional test like SimpleTest, one is rightly scared to change the test. With an isolated unit test, you have a baseline and you can see if what you're changing breaks the test in the way you predict that it will break, without having to run a SimpleTest that takes ten years and then you still have to reverse-engineer the result. You can also read the diff of the test to find out what expectations changed when it comes time to review a patch.
I think if you give this style a chance, you'll see it's benefit.
I'd suggest keeping it, as per patch #28, but you're the maintainer. :-)
Comment #38
daffie commented@alexpott wants testCoptConfig() and providerCopyConfig() removed from the patch and that is done. So back to RTBC.
Comment #39
alexpottLet's add to these so that the difference between assertEqual and assertIdentical is exposed and tested.
Comment #40
mile23OK. So there is now only one data provider for
testAssertIdentical(),testAssertEqual(), and their *Not brethren. It covers more tricky comparison issues.Comment #42
mile23Hello, MigrateFileTest! Thanks for ruining my day! :-) #2417549: Drupal\migrate_drupal\Tests\d6\MigrateFileTest fail in MigrateTestBase
Comment #44
mile23Passes now.
Comment #45
daffie commentedIt all good good to me with one exception:
Should this test not use providerAssertIdentical as its dataprovider?
Comment #46
mile23You mean this?
$expectedgets flipped with!.Comment #47
daffie commented@Mile23: My typo mistake! No, I mean that it should be: "@dataprovider providerEqualityAssertions".
Comment #48
mile23I see what you mean... Is this what you had in mind?
Comment #49
daffie commented@Mile23: Yes, that is what I had in mind.
It all looks good to me.
All documentation is in order.
This is about tests so as a beta change it is allowed.
It get a RTBC from me.
Comment #50
alexpottAre you sure about this? Like do you know why this is here?
Comment #51
alexpottLol I answered this myself in #36 :)
Committed a954b05 and pushed to 8.0.x. Thanks!
Thank you for adding the beta evaluation to the issue summary.
Comment #54
alexpottAfter committing this patch.
Comment #55
daffie commentedComment #56
mile23I guess it's reasonable to remove that data set. Funny that it never gave me a problem.
I'd RTBC but it's my patch you just modified.
Comment #57
daffie commentedMile23 agrees with my change so back to RTBC.
Thanks for your review Mile23.
Comment #58
alexpottCommitted 9305a47 and pushed to 8.0.x. Thanks!