A Strange Sort of Prison, a Strange Sort of Freedom
(via Instapaper)
(via Instapaper)
(via Instapaper)
(via Instapaper)
(via Instapaper)
(via Instapaper)
(via Instapaper)
I found many posts relating complaints about how painfully slow git auto-completion can be in large repositories. There were various suggested patches and suggestions to load the latest zsh. Maybe one of those things would work, but all I really want is for it to complete the names of branches and files as they are in the file system. I did not find any suggestions on how to get this behavior so I figured it out for myself. I thought I would share this for anyone who might benefit from it. I just added the following to my .zshrc file:
__git_files () {
_wanted files expl ‘local files’ _files
}
Now I can run git commands and get near instant completion while still getting file completion similar to what ls would provide.
(via Instapaper)
(via Instapaper)
Lesson: Don’t use InSequence unless you have a really good reason to do so.
It is obvious that requiring mock calls to be in a particular order leads to fragile tests. I can deal with that. What may not be so obvious, is that the tests may fail in ways which don’t immediately lead you to deduce what caused the failure.
I added a new mock class and a new EXPECT_CALL, and didn’t notice that it fell after an InSequence meant to govern calls on a different mock. The code segfaulted with:
Unexpected mock function call - returning default value. Function call: getFoo() The mock function has no default action set, and its return type has no default value set.
I could clearly see that I was setting the default action. As this was the first test in the suite and the tests stopped cold on the segfault, I couldn’t see the reason it didn’t think there was a return value specified. It wasn’t until I reordered the tests and started comparing a test that worked line by line with the test that failed that I discovered the issue.
By that time I was already stressed out, something unit tests are supposed to alleviate, not cause. Of course, it would have been nice if google mock would have indicated an out of order mock call, instead of this failure. I’m not sure how difficult that would be to fix.
In the mean time, I may shy away from InSequence and it ilk. But, I will still be using google mock. Hopefully I will continue to post tidbits I learn as I delve futher into unit testing, TDD and mocks.