By Mike Mengell, Application Development Manager at Microsoft

If you’re a web developer you probably do at least some client side development you also probably already use some developer tooling. IE11 was released with Windows 8.1, with this release was the newest version of the F12 developer tools. The F12 tools have been completely rebuilt since the previous version, it has some really useful tooling which I’ll cover elements of in this article. In the past I’ve seen developers (and done myself) doing the majority of their development using Chrome as the developer tools are very powerful even if the business is targeting IE exclusively. There is a process in the development cycle to try and get the same functionality working correctly in IE. This approach is somewhat fragmented. If you’re targeting IE then develop against IE. While I am a big advocate of making every site a cross browser experience I am also a lean developer and if I don’t need to build it then I won’t.

Using the newest version of the F12 tools is a much nicer experience than previous versions. The tooling looks nicer with a clean high contrast interface. Within the developer tools the areas of functionality are organised into tabs; DOM Explorer, Console, Debugger, Network, UI Responsiveness, Profiler, Memory, Emulation. Depending on the type of application you’re building you will spend more time in various sets of tabs. For instance if you’re writing a HTML5 game then you will spend most of your time in Console, Debugging, UI Responsiveness, Memory. If you’re writing a Single Page Application you will favour Console, Debugging, Memory and Network. For line of business applications which typically have less focus on JavaScript you would use Console, Network and DOM Explorer. It is important for you to have a basic understanding of all the tools available for solving problems down the line and I encourage you to invest some time to dive into each tabs functionality.

However I wanted to focus on the Console as it’s got some useful features which can help to diagnose issues in any application type. I personally really like test driven development and all the benefits which come with it. I thought I’d use this love of testing combined with my love of JavaScript and build a basic implementation of a unit test framework within the console. This is an academic exercise and not something to do in a production environment. But it will serve well to highlight some functionality of the console which you should be aware of.

First things first, to open the F12 developer tools you need to press…you guessed it F12. If you’re using a Surface keyboard then you need to press Fn + Page Up. The F12 tools can run docked in the current IE tab or undocked, but it will retain a link to the tab it was opened in. If you want to use the F12 tools over multiple IE tabs then you need to select the tab you’re targeting then press F12 again. This will open multiple instances of the F12 tools each linked to its original IE tab. Opening the F12 tools will no longer cause a refresh on the web page which was previously jarring to the developer.

You can use keyboard shortcuts to navigate to each tab (Ctrl+1-8). Once in the console tab (Ctrl+2), you can flip the console into multiline by pressing Ctrl+Alt+m. If we’re going to build a test framework we need a way to run a test. This can be done by creating an assert function;

Our test framework will need a way to output the result of a test. For this we need a new output function;

We can use the F12 console object to log errors to the console by using ‘console.error’. This will make the visualisation of the errors much more prominent, which we will see shortly. Coming from a C# background the pattern of concatenating strings is grating on me. I would really like to use something like C#’s String.Format function here. Luckily the F12 tools give us something similar we can use. We can use variable substitution. Let’s explore this functionality, take the following example code;

We have 3 variables each with a different types. Using variable substitution we can use the %s, %i, %o to substitute a string, integer and object respectfully. There is also %f for float and %d for integer. I have overridden the toString function of the object as it will get called as part of the substitution process. The output of this is a string, therefore each objects toString method will be called. The default toString method of an object is pretty much useless, so it’s best practice to override this to output some internal state of the object. This pattern should also be adhered to in C#.

Using this new found knowledge lets improve our output function;

Now we have an output function we can use it in our assert function.

The last piece is to create a test for us to run. We should pass in the simplest test possible to make sure it all works correctly. For that we can just test that true is not equal to false, then execute it;

This will give us some output in the console window. If we add a second test which will certainly fail then we can see the visualisation of this on the output window.

 

If you run this code a second time then you’ll see that we get more errors, this is because we’re not clearing the console output between execution. We will want to add a console.clear() call to our code, the first line is fine. In the same way we are logging errors we can also log warnings and information messages using console.warn(‘text’) and console.info(‘text’). It’s good to be as specific as possible so we will change the output function to use console.info when we have a passing test.

We have a functional JavaScript test runner but it’s a little clunky. I’d like to be able to more easily build and run new tests. For this we need a concept of a test case. We can add a testCase function then refactor our code to use it;

This makes our testing framework functional if not obviously incomplete. I wouldn’t recommend using this in a production environment, I’m hoping you notice a few reasons why not too.

I mentioned at the outset of the article that the F12 tools have built completely rebuilt for this version. However what I neglected to mention was the language which was used. It may be surprising to learn that it was developed with TypeScript. TypeScript is a new superset of JavaScript based on the emerging ECMA Script 6 standards. The TypeScript compiler will output valid idiomatic JavaScript, over 250k lines of JavaScript. This means that the F12 tools contain solely JavaScript by the time it is installed on your computer. You can actually see the JavaScript code for the F12 tools. If you locate the F12Resources.dll you can extract the complete F12 code base using a resource extractor (not managed code). This can be a great way of learning how to organise code and coding standards on a large project. I would encourage readers to crack open the DLL and take a look. As with any JavaScript application you can view the code base and get a deeper understanding of the application.

If you want to learn more about the F12 tools then the MSDN documentation is very comprehensive and found here. If you’re a fan of videos then there was a good overview of the whole tool set at Build by a couple of the dev team, Carl Edlund and Jonathan Carter, which can be found here.


Mike works in the Premier Support for Developers team at Microsoft, giving your business access to developer resources and support to accelerate software development and help ensure project success.