Keep track of all the latest news and events on developer tools and technologies you care about
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.
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.
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.
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.