-
Notifications
You must be signed in to change notification settings - Fork 87
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Edit tight coupling runLog
s + refactor tight coupling unit tests
#1172
Conversation
- resolves a wierd discrepancy where a unit test would fail in the debugger if left as a generator
- helps with readability and isolation of different assertions
- move to their own class and remove need for loadTestReactor
class TestTightCoupling(unittest.TestCase): | ||
def setUp(self): | ||
self.cs = settings.Settings() | ||
settings.setMasterCs(self.cs) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@john-science this is the culprit.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I mean, if this HAS to go in for this PR, I will hold my nose and do it.
But we WILL have to add it to the list to remove ASAP:
runLog
s + refactor tight coupling unit tests
- just for tight coupling settings for now to keep scope appropriate
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some comments and suggestions
Co-authored-by: Arrielle Opotowsky <arrielle.opotowsky@gmail.com>
Co-authored-by: Arrielle Opotowsky <arrielle.opotowsky@gmail.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for adding a little extra pizazz to a unit test for me!
To unblock this PR from being merged, I'm going to dismiss Mark's review since the changes he requested are addressed. |
self.assertTrue(self.o.couplingIsActive()) | ||
self.o.cs[CONF_TIGHT_COUPLING] = False |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
above you have self.cs
defined than an operator init-ed from that, so can this be self.cs[CONF_TIGHT_COUPLING] = False
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
same applies below in lines 146, 152, 224
I guess it doesn't actually matter
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It could since both self.cs
and self.o.cs
point to the same cs object in memory. My thoughts on the self.o.cs
route: once we get rid of set/getMasterCs
, self.cs
and self.o.cs
could be different. So the assertions should live on self.o.cs
I think. What do you think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
fair!
This PR is....gasp...READY
Description
This PR addresses the following:
loadTestReactor
; these tests don't need a full reactor so there's no reason to build one.Checklist
doc/release/0.X.rst
) are up-to-date with any bug fixes or new features.doc
folder.setup.py
.