Telerik blogs

Latest

  • Productivity Debugging

    Fiddler ImageView Enhancements

    The latest Fiddler beta v2.4.2.5 (targeting .NET2 or .NET4) includes several improvements to the ImageView Response Inspector. While its appearance remains mostly unchanged, the new version provides much more insight into the metadata often included with image files. Read on for more details.
    January 18, 2013 7 min read
  • Productivity Debugging

    Fiddler ImageView GeoLocation

    In my previous post, I discussed the recent enhancements to Fiddler’s ImageView extension that expose metadata about image files under inspection. My initial goal in exposing metadata was to help you optimize the size of images in order to build faster websites. However, in some cases the privacy implications of such metadata can be of far greater concern.
    January 17, 2013 3 min read
  • Productivity

    Telerik OpenAccess ORM – Your Feedback Does Matter

    As many of you are already aware, we have been delivering many of the top requested features by the community with each official release of Telerik OpenAccess ORM. Database Default Values, Database Functions support and Native 1:1 Relationships are only a few of the most recent examples.  Click to continue...
    January 16, 2013 2 min read
  • Productivity Debugging

    Manipulating Traffic with Fiddler Extensions

    A key advantage Fiddler has over a traditional packet sniffer or in-browser network monitor is the ability to modify the traffic. This can be done manually (using breakpoints and Inspectors) or automatically, using FiddlerScript or extensions. In today’s post, I’d like to introduce one such extension—ContentBlock
    January 14, 2013 5 min read
  • Productivity Testing

    Asserting Behavior with JustMock

    JustMock is a great tool for abstracting dependencies in unit tests, and the new automocking feature makes it even faster to develop unit tests.  Another great feature in JustMock and JustMock Lite is the capability to assert the behavior of your system under test.  Traditional TDD (Test Driven Testing) unit testing typically tests for state.  Did the user get logged in? Did the user’s shopping cart get loaded?  Important tests, of course.  But that only tests the end result of the method.  If the user does NOT successfully login, and the cart is not reloaded, is that because the call to the repository was never called? Or because some error happened that didn’t reload the cart in this particular use case?  The state of the application is correct, but is that because it executed the expected behavior, or because we got lucky? 
    January 10, 2013 5 min read