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.
Intern is a great test stack for writing full-featured unit and functional tests, with remote WebDriver-based testing (e.g. Sauce Labs) and continuous integration (e.g. Travis CI). Debugging failing tests can be a challenge if you don’t know the most efficient techniques for troubleshooting platform-specific issues or problems with your test cases.
Our first year of Intern has been a big one! It became a top trending project on GitHub for the month of our first release and has gained over 100 community forks and nearly 1700 stars so far. It’s in use today by tons of companies with names like Alfresco, Esri, IBM, Intuit, Mozilla, and Stripe. Because we believe so strongly in the power of testing, especially as Web applications continue to grow in size and complexity, we’re excited to continue our investment in Intern and its supporting technologies in order to provide the best possible testing experience for all Web developers.
Here’s a look at some of what’s coming to Intern this summer:
Last month, we conducted a live webcast to provide an Introduction to Intern, SitePen’s open source testing framework.
Our webcast covered:
- An overview of Intern’s numerous functional and unit testing features and capabilities
- Mocking objects and data
- Injecting dependencies
- Future direction of Intern
While it’s too late to attend this webcast and heckle us with live questions, we recorded the session and have made it available for you online: