- Feature Articles
- CodeSOD
- Error'd
- Forums
-
Other Articles
- Random Article
- Other Series
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
After her (presumably) frist role in programming, did Rhonda's colleague go on to write embedded software for VW group diesel ECUs?
Admin
Should have provided individual mockeries for all the tests. If there were some other way to do this.
Admin
Paula, was that you?
Admin
I took over a huge codebase with thousands of "if (test)" conditionals. I've listened to people make long passionate arguments about why there is no problem with it.
The worst case is that much of our most critical code is written as:
if (test) return true; else return actuallyDoTheWork();
… and everyone that works here wonders why testing is so difficult and why acuallyDoTheWork() is so full of bugs.
Admin
How do you mock HttpContext?
Admin
Please bear with the ridiculously contrived example, but something like this, perhaps?
Admin
Reminds me of the tests I inherited at a former job. For example, some were to look up an account by id, and verify that the account name was X, or the account contact's name was Y.
Of course, there were administrative functions for those data, so when they changed, the build would break.
No blame; they were in the early days of trying to figure out how to write good tests.
Admin
Or don't. Move the calls to HttpContext into services and mock the services.
Admin
Missing the first line above:
Admin
You don't. Select is not broken. HttpContext is not broken either. Just use the real one.
What you do is have a development environment that points to a test server that you interact with rather than the production server.
Admin
You Must Be New Here.
Admin
In their infinite wisdom, Microsoft made HttpContext unmockable originally, and then introduced MVC and testability but instead of extracting HttpContext into an interface like IHttpContext, created a whole new base class called HttpContextBase, which has a child class HttpContextWrapper which you guessed it, wraps around HttpContext. Long story short, write everything to use HttpContextBase.
In .NET Core, they improved on this, making HttpContext itself an abstract class. (Why not an interface?)
Admin
The other option which is very possible but somewhat dirty is to create a HttpContext and populate it with mock values using reflection.
Admin
OK they tested the 27 year old John Smith. What about 76 year old Dorothy Wilkins? Very poor coverage.
Admin
Not to defend the loony who wrote the code referenced in the OP, but there is actually a case for an "if (test)" switch.
I'm working on an enormous CAD/CAM product, and I need to test the Model. (I'd like to test the View, but that's a different issue.)
I've mocked up just about all the calls into the view that I can, but sometimes it's necessary to test a part of the Model that depends upon behaviour in the View. You may think this is a code smell. So do I. But the easy way to deal with this is to have a (nasty) global flag called "InTest" that allows you to branch around dealing with GUI issues and the like.
Not ideal, but expedient. And nothing like the wretchedness displayed by today's WTF.
Admin
If you were talking about Java, I'd just tell you to use Mockito.
Admin
@ooOOooGa ref:
And how do you test the error handling code that has to react to every possible unexpected value or result coming from HTTPContext. Or if not from that class, some other equally challenging Framework class?
Yes, I totally accept that e.g. HTTPContext is good code. But it can still report failures to me that I must handle. Which means I must test those handlers.
Admin
It's a joke
Admin
that's not a mockery, that's just the Volkswagen Technique: if(beingTested) return valuesThatPassTheTest; else return realValues;
Admin
That would make it an integration test, not a unit test. Integration tests are good and useful, but serve a different purpose (and are much heavier weight). You have the unit tests to try to catch problems at the easy-to-find stage when you don't have too many bits and pieces interacting with each other.
Admin
Why not just use the real HttpContext? For one thing, that is no longer a unit test, it's an integration test. Which is fine - unless you want a unit test.
Admin
Even poorer. They don't test age < 0. Maybe because they couldn't find out how to name an unborn person.