New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 662476 link

Starred by 1 user

Issue metadata

Status: WontFix
Owner:
Last visit > 30 days ago
Closed: Nov 2016
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 1
Type: Bug



Sign in to add a comment

[Predator] Create an Testcase similar to the current testcase in app engine to allow easier local unittesting.

Project Member Reported by kateso...@chromium.org, Nov 4 2016

Issue description

[Predator] Create an Testcase similar to the current testcase in app engine to allow easier unittesting for local scripts.

Especially this LocalTestCase should allow users to use self.mock to mock functions.

Move run_test.py script to the util_script/ to run all the unittest for local scripts.
 

Comment 1 by st...@chromium.org, Nov 4 2016

Instead of a self.mock, could we just use the mock framework?

Comment 2 by st...@chromium.org, Nov 4 2016

Why we need run_test.py as a separate unittest runner? Can we just fit in the infra testing setup?
could we just use the mock framework?

2) It's easy to implement the self.mock function as in production code.
1) I want those tests in util_scripts/ be similar to other unittest to be consistent. This is just the way other tests are using.
3) There are already many unittests rewritten in self.mock format, this way can save time and effort in a clean way. :)

Why we need run_test.py as a separate unittest runner? Can we just fit in the infra testing setup?
Yes, we can use a hack in __init__.py to fit in the infra testing setup.
> 1) I want those tests in util_scripts/ be similar to other unittest to be consistent.

FWIW, I've been trying to get rid of the use of self.mock in the unittests, because it makes the tests extremely fragile and very difficult to debug. So trying to match the current unittests isn't a good motivation.
But it is the infra repo convention, isn't it?
What's your plan to get rid of it?
In lots of places, it's sufficient to create (sub)classes which mock out the relevant methods.

I'm not saying we should jump through hoops to get rid of every single use of self.mock; there are some places where self.mock is the most straightforward approach. But we want our tests to be robust against changes in the underlying code. The more that tests depend on the guts of an implementation (which using self.mock almost invariably does), the more fragile they are. Whereas the more that tests depend only on the arguments and results of functions, the easier it is to change around the implementation of those functions without causing the tests to crash or spuriously fail.

Comment 7 by st...@chromium.org, Nov 8 2016

We are moving to unittest.mock wherever possible; the self.mock is not the best approach although it is helpful in some cases.

katesonia@:
I cced you quite a while on this CL https://codereview.chromium.org/2158533002/
I guessed you just skip those CLs I cced you :)
Components: Tools>Test>Predator
Components: -Tools>Test>FindIt>Crash
Status: WontFix (was: Assigned)
stgao@, right, I missed that... closed this issue.

Sign in to add a comment