There's a lot of reasons that Visual Studio hangs. It was hanging for me the other day when I tried to open, and I had a clean checkout. One solution that solved my current problem (thanks to a co-worker):
2 seconds later, VS was up and running.
A lot of eager students will be graduating with CS degrees soon. Realistically, with almost 10% unemployment, out-sourcing, and a rough economy, it can be hard for a college-grad to find a tech job.
Here's a brain-dump:
Sometimes I wish development were as easy as telling junior guys to "follow this one metric", and then they write perfect code. However, it's not. One example is how to know when you've written enough unit tests. Code Coverage is the obvious metric, and therefore "100% Code Coverage" sounds great. But there are plenty of cases where even 100% coverage doesn't do the job.
Case 1: Regular expressions
Take an email validator, something like so:
public static bool IsEmail(string s)
{
return System.Text.RegularExpressions.Regex.IsMatch(s,
@"\b[A-Z0-9._%+-]+@[A-Z0-9.-]+\.[A-Z]{2,4}\b");
}
A single test would give 100% coverage, but obviously there's a lot of other paths to check. Ironically, because regular expressions are often used to validate input data, and it's an in-memory operation (no databases or external files to hit), it's a prime candidate for lots of unit tests to catch all the boundary conditions - as opposed to just the 1 test needed to reach 100% coverage.
Case 2: Single-line expressions
Similar to the previous case, merely calling this method with one set of inputs (say the "less-than" path, such as i1=5 and i2=10), will get 100% coverage. But that wouldn't test the "greater-than" and "equal to" conditions.
public static bool IsGreater(int i1, int i2)
{
return (i1 > i2);
}
Case 3: Missing Asserts (bad logic)
Even with 100% coverage, it doesn't guarantee that the method logic is correct.
For example, say you've got a CSV-parsing method:
public static string[] ParseCsvString(string strLine)
{
string[] astr = strLine.Split(',');
return astr;
}
That is tested by:
[TestMethod]
public void ParseCsvString()
{
string[] astr = Foo.ParseCsvString("a, b, c");
}
This will give 100% coverage. However, there are no asserts, so it's really just showing that the method didn't throw an exception. Even if a developer adds an assert, they need to make sure it's asserting the right thing. Say, adding an assert that the returned array is not null, or has a length of 3, misses the logic that trims the white space after each comma. For example, we want elements like "b" (no whitespace), not " b". In other words, we'd want the ParseCsvString method to loop through each item and Trim() it.
Case 4: Mocking giving a false sense of security
Mocking Frameworks, like TypeMock, are very powerful tools for increasing unit test coverage. These tools allow you to "mock out" a method call within code, such as that database or logging call that would be hard to run in a test method.
While this is great for testing legacy code, it can easily be abused. If every line is mocked out, there's nothing real that's left to test. So while it does get high coverage, if used incorrectly, it becomes meaningless.
One such book I read was John Maxwells' Winning with People. It was a Christmas present. John has written dozens of books about people, leadership, relationships, and all that. He's got a lot of wisdom. The book is a series of short chapters on various principles like "Never let the situation mean more than the relationship", and "the journey with others is slower than the journey alone." I found it practical, avoiding the common sense clichés like "be nice, work hard, etc..."
I saw a few big take-aways:
The book is also filled with good quotes, like:
See also:
BOOK: Making Things Happen, BOOK: Bringing Out the Best in People
| Description | Example | PRO | CON |
| Send web requests, and then parse the corresponding response. | MSTest WebTests |
|
|
| Directly tap into the ASPX pipeline (I'm no expert here, but to my limited knowledge, it seemed different than merely the request-response model). | NUnitAsp (but this was officially ended) |
|
|
| Recording and playing back the mouse and keyboard movements | Don't know offhand, but I've heard of them with COM+ |
|
|
| Run the browser in an automated script. | WatiN |
|
|
Personally, I've seen the best luck with WatiN. Especially in the Ajax age, automated tests need to run JavaScript. I also find that to get a team to adopt a new tool, it's invaluable to let them run it themselves (i.e. anyone can download the open-source tool and run it with management paying $$$ for a license), and to provide tutorials (i.e. WatiN has an active community).
What constitutes broken code? Everyone agrees that code that crashes in production and threatens to have developers fired is indeed broken. But where's the line? Is the following code broken:
In all these cases, say the application essentially "works" and handles the main use cases.
The problem is maintenance. Maintaining and extending code is an expensive part of the total cost of ownership. You could spend hours tracking down a single erroneous line of code. Code that is low quality (tons of copy & paste, misnamed methods, misleading logic, etc...) is going to be a fortune to maintain. On the other hand, certain functional errors that have zero impact on the business can perhaps be documented as "known-issues" (i.e. the month is formatted in a label with a preceding zero like "03" instead of just "3".
I'd say it comes down to the business, and the code is broken if it costs the business more than it should - whether it be via maintenance costs or functional errors that hinder the end users. Perhaps the question isn't as much "is this code broken", but "how can we maximize the business-value of this code?"
I am a huge advocate of unit testing. After years of writing tests, and encouraging other devs to write tests, I find five common ironies:
