• MiserableOldGit (unregistered)

    After her (presumably) frist role in programming, did Rhonda's colleague go on to write embedded software for VW group diesel ECUs?

  • Edd (unregistered)

    Should have provided individual mockeries for all the tests. If there were some other way to do this.

  • Michael (unregistered)

    Paula, was that you?

  • (nodebb)

    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.

  • CarComp (unregistered)

    How do you mock HttpContext?

  • Naomi (unregistered) in reply to CarComp

    Please bear with the ridiculously contrived example, but something like this, perhaps?

    @ExtendWith(MockitoExtension.class)
    class WidgetTest {
    
        private @Mock HttpContext context;
        private @Mock HttpHandler handler;
        private Widget instance;
    
        @BeforeEach
        void setup() {
            instance = new Widget(context, handler);
        }
    
        @Test
        void getNormalizedPath() {
            when(context.getPath()).thenReturn("foobar");
            assertEquals("/foobar/", widget.getNormalizedPath());
        }
    
        @Test
        void start() {
            instance.start();
            verify(context.setHandler(handler));
        }
    
    }
    
  • Scott (unregistered)

    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.

  • (nodebb) in reply to CarComp

    How do you mock HttpContext?

    Or don't. Move the calls to HttpContext into services and mock the services.

    {
      string GetUserName();
    }
    
    public class WebServerWhoAmI : IWhoAmI
    {
       public string GetUserName()
      {
        return HttpContext.Current.User.Name;
      }
    }
    
    public class MockWhoAmI : IWhoAmI
    {
       public string GetUserName()
      {
        return "A Test";
      }
    }
    
  • (nodebb)

    Missing the first line above:

    interface IWhoAmI
    
  • ooOOooGa (unregistered) in reply to CarComp

    How do you mock HttpContext?

    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.

  • (nodebb) in reply to ooOOooGa

    What you do is have a development environment that points to a test server that you interact with rather than the production server.

    You Must Be New Here.

  • (nodebb) in reply to CarComp

    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?)

  • (nodebb)

    The other option which is very possible but somewhat dirty is to create a HttpContext and populate it with mock values using reflection.

  • (nodebb)

    OK they tested the 27 year old John Smith. What about 76 year old Dorothy Wilkins? Very poor coverage.

  • Sole Purpose Of Visit (unregistered) in reply to Jaime

    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.

  • Shill (unregistered) in reply to CarComp

    If you were talking about Java, I'd just tell you to use Mockito.

  • WTFGuy (unregistered)

    @ooOOooGa ref:

    You don't. Select is not broken. HttpContext is not broken either. Just use the real one.

    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.

  • CarComp (unregistered) in reply to Jaime

    It's a joke

  • sh_code (unregistered)

    that's not a mockery, that's just the Volkswagen Technique: if(beingTested) return valuesThatPassTheTest; else return realValues;

  • (nodebb) in reply to ooOOooGa
    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.

    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.

  • nasch (unregistered)

    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.

  • Dudain Official (unregistered)
    Comment held for moderation.
  • desi news (unregistered)
    Comment held for moderation.

Leave a comment on “Absolute Mockery”

Log In or post as a guest

Replying to comment #:

« Return to Article