Today we’re happy to announce the release of Intern 2.1. This release contains several bugfixes and improvements to existing functionality, as well as new features to make running tests and handling test results easier. The full list of enhancements and bugfixes is available in the release notes. Here are some of the highlights!
More output options
Two new reporters have been added to Intern: an HTML reporter for the browser client and a JUnit XML reporter.
The HTML reporter is a new default reporter for Intern’s browser client runner (
client.html). It displays at the end of a test run, summarizing the test results and presenting them in an easy-to-read format:
The output of the JUnit reporter, on the other hand, is meant for machine consumption. It aggregates test results and outputs them in a
report.xml file that follows generally accepted standards for JUnit-compatible XML. This makes it much easier to plug Intern into tools that accept JUnit reports, like Jenkins.
While TypeScript is very simple to understand when performing basic tasks, having a deeper understanding of how its type system works is critical to unlocking advanced language functionality. Once we know more about how TypeScript really works, we can leverage this knowledge to write cleaner, well-organised code.
If you find yourself having trouble with some of the concepts discussed in this article, try reading through the Definitive Guide to TypeScript first to make sure you’ve got a solid understanding of all the basics.
When developing for the web, it is a recommended best practice to always test your application during development with a web server. This is for two primary reasons. By running a web server, you can approximate a production environment similar to how your application will be served to your users. Also, browsers implement a same-origin policy that is different for quasi-protocols like
file://. Many of Dojo’s modules like
dojo/text, Dijit templates, and
dojox/gfx depend on loading files from the same origin.
A common practice when adding new elements to a document is to add them to a container DIV and then insert that node into into a document. A lesser used alternative is the
DocumentFragment class. So, what is a document fragment, and when should you use one instead of a container DIV?
When writing tests for an application, it’s prudent to add mock or stub data in order to allow code to be properly tested in isolation from other parts of the system. Within a normal Dojo application, there are typically three places where mocking will occur: I/O requests, stores, and module dependencies.
Many of the best practices for writing testable code also conform to general code best practices. Code that is easily testable often also tends to be highly maintainable and resilient against changing business requirements. This blog post provides a brief overview of key criteria for writing highly testable code.
At SitePen, we have long been advocates for building web applications on a RESTful architecture. Over the last several years, it has been exciting to see organizations increasingly provide RESTful endpoints for the Dojo-based front-ends that we support and develop. A well-designed REST backend can be a excellent foundation for manageable, scalable applications, that will be ready to evolve into the future. I wanted to share a few tips for designing a set of RESTful services.
The first day of the conference had many great talks. The one that stood out the most to me was the User Interface Algorithms talk by Mark DiMarco. He described Voronoi Diagrams and, using The New York Times’ 512 Paths to the White House page, shows how they are used to determine which path to highlight in a tree based on the mouse position. He then examined the Amazon drop-down menu and explained how it knows when to keep submenus open.