What do you do when your “small” ergonomic chair is actually taller than your original chair? Sigh. Well, at least with the armrests off, I can finally lower my desk to the proper height.
And to think I was a soccer goalkeeper in high school. At least the old saying, “A ball shot low never misses” always worked in my favor.
It’s really the simple things in life. Ever had a long list of parameters for a method and didn’t want to have to look down at the tooltip to know where you were at in this list? Check out Edit.PasteParameterTip. Under the General Development Settings, it is mapped to Ctrl+Alt+Shift+P, but you can change this to whatever you want under Tools – Options – Keyboard.
For example, suppose the method Foo below contained 4 or 5 parameters.
this.Foo(
Leaving the cursor right after the open parenthesis (and the tooltip showing), hit Ctrl+Alt+Shift+P. Results…
this.Foo( int i, string j, int k, string l, int m, string n )
Now you can just update the parameters with your variables without having to follow along with the tooltip.
update 1/21/2005 – 2:30pm
By the way, there’s a corresponding Edit.CopyParameterTip Ctrl+Alt+Shift+C. Forgot to mention earlier.
Do you have any software testing topics you want to hear more about? Here are a few suggestions that I’ve already received from readers:
Let me know what other topics you’re interested in and I’ll see what I can do…
Josh went around and video’ed a bunch of us at work in our offices. It has been an interesting experience sharing an office with the PM for the features I’m testing, to say the least. My job is to break all the stuff that Sean demo’ed, and then to write the automation to break it some more.
You might notice the sign language on the back of my t-shirt. This was a t-shirt a bunch of us designed and distributed to members of my virtual Visual Studio Accessibility team last year. The back says, “Visual Studio .NET codename Whidbey”. The front in Braille grade 1 says “Accessibility Police.” It was a thank you gift to my virtual team for all the hard work they did to make Whidbey accessible.
And by the way, if you send me an Xbox Live friend request, send me a quick email letting me know who you are, so I can separate the friend requests from those who are mad about “you were killed by OMG a girl” and later want to take revenge in a 1-1 (yes, this has happened) versus the friend requests from those who read my blog.
Part 1
http://channel9.msdn.com/ShowPost.aspx?PostID=35379
Part 2 – Sean and I are right at the beginning demoing Code Snippets
http://channel9.msdn.com/ShowPost.aspx?PostID=35563
Description
If you are unfamiliar with the File Tab Channel, check out my post about it at
New Window Management Features for Visual Studio 2005.
Nightly Scenarios
Note: If you would like to seed feedback, but the comments are closed, please feel free to contact me via the contact form.
Description
If you are unfamiliar with Tool Window Docking or Dock Targets, check out my post about it at New Window Management Features for Visual Studio 2005.
Nightly Scenarios
Note: If you would like to seed feedback, but the comments are closed, please feel free to contact me via the contact form.
Description
If you are unfamiliar with the IDE Navigator, check out my post about it at
New Window Management Features for Visual Studio 2005.
Nightly Scenarios
Note: If you would like to seed feedback, but the comments are closed, please feel free to contact me via the contact form.
A couple of months ago, I posted an entry called What is a Nighlty Test Case? I mentioned how I’ve been tasked with coming up with a way to share our team’s nightlies with the community for review. I’ve been working on this off and on this week, and I now have several nightlies ready to be posted.
In all fairness, especially since this is something we haven’t done before (to the best of my knowledge), I’m going to post three nightlies that I originally wrote the test spec, implemented the library work, and wrote the test case code for. Even though I own the Editor now, it just didn’t seem right to me to post someone else’s work to “test the waters.” Anyways, I have thick skin, so let me know what feedback you have. Seriously, we want to hear your feedback.
Once I get a good feel for how to post the nightlies (as articles? As individual posts or combined posts? Etc.), we’ll start posting other feature areas for review on the team blogs. I??m just using my blog right now as the testing-grounds, but if I wrote it, it’s going to show up here, regardless.
If I could, I would disable the 30-day limit for posting comments. I’m hoping that if people have comments after the 30-day limit, they’ll use the blog contact form. I’ll mention this at the bottom of every Nightly post as a reminder that people can still send feedback. Hopefully one day we’ll be able to disable this on a per post / blog basis.
Just got back the results tonight from my 2nd Kyu exam. The only comments were about my back fist strike not having enough snap, but this is something I’ve been aware of. And there was a comment to make the motions of my kata a little bigger. The head sensei and I are going to watch the exam video the next time I sync up with him to see just what I need to correct in my kata.
The really good news about passing is that this means I’m on track now to test for Black Belt in November. I first started doing Shotokan Karate when I was 14, so knowing that I’m finally in the queue for testing for black belt is a dream come true.
As promised, I said I would ask some of the people from my team after they returned from vacation about the history of LogPass. I met with one of our SDET Leads to find out more. Here’s what I learned.
Logging failure by default is a Test-Driven Development best practice.
Logging failure by default is a good best practice because it catches mistakes made by the test case writer. For example, here’s a scenario that would only be caught by logging failure by default unless the test case writer explicitly calls log pass.
‘ begin scenario 1
If CurrentFileName = “foo” Then
‘ do specific verifications for foo
‘ log pass if correct
‘ otherwise, log failure
ElseIf CurrentFileName = “bar” Then
‘ do specific verifications for bar
‘ log pass if correct
‘ otherwise, log failure
End If
‘ begin scenario 2
Suppose the current file name was “TextFile1”. If we didn’t log failure by default, this scenario would have simply succeeded, because it never had the chance to do any verifications. Logging failure by default means that you check assumptions made by the test case writing. As in the above example, log failure by default catches the assumption that the file name will always be either foo or bar.
And another way to look at whether to log failure or to log pass:
It is an optimization for quality when log failure is default.
It is an optimization for time when log pass is default.