Testing static html/css

Testing
1

I am new to testing, and am curious how much I should be testing my static HTML/CSS, especially at the beginning of a project, when I know my HTML structure will change often as I figure things out.

Basically, I’ve been writing tests only for my Javascript code. If I start out with static templates, I don’t start testing until I add behavior.

Is this good practice?

2

Testing should be a part of any Ember application. It is very easy to get up and going. The best example I can point to is the Ember Starter Kit (https://github.com/emberjs/starter-kit). It has good examples of Integration testing your app.

3

Right, but what about testing HTML/CSS only, that is, only templates? Is there a place for testing there?

4

@samselikoff I posted some thoughts on testing Ember apps here: Pixelhandler's blog

The article needs updating or perhaps a follow up article with current helpers, ember-testing setup etc.; But I did include a section Testing Strategy which lists my opinions about testing an ember app.

I recently recorded a quick screencast on integration testing with Ember here: Overview of end-to-end (integration) testing with ember-app-builder on Vimeo The client-side testing starts about 3 mins into the 6 min video (first half is server tests)

As for testing HTML… When writing integration tests, I like to test the result of my rendered templates. So I may assert / expect some text or css classes are present. However I do not test CSS, except for things like hide/show etc.

If you are interested in reviewing test code for an ember app, my blog is written with Ember and I have an integration test suite written for the app shared at: https://github.com/pixelhandler/blog/tree/master/client/tests/integration

My approach to integration testing with Ember is to test for each feature, starting with the simplest thing like a list of links in a menu, then move on to a button that loads more, then perhaps a login form, next the create, edit, delete actions for a web form… and so on. The integration test suite should grow with the set of features. I also like to write the test (failing) then write the feature to pass the test (TDD). However when trying to figure out how Ember works I may just build a part of a feature then once I figure out how the feature is supposed to work in Ember I write a test and continue, etc.

Hope this helps you with your testing strategy.

1 Like
5

Hey , thanks so much for this! Plenty for me to dive into.

Really appreciate your thoughts.

6

@pixelhandler One more question while I have you, if you don’t mind. When you started your blog,

  1. Did you first code up a ‘static’ version of it, and then slowly add behavior by moving things around, extracting pieces into components, etc.
  2. Or did you first sit down and think about the UI, and which pieces would be components, before you started coding at all?
7

@samselikoff, here’s my reply:

  1. Yes but not slowly, 1st I built a working html/css prototype for the layout and content styles. Then I split up the HTML into handlebars templates using an Ember app starting with the index page and menus.
  2. Since this is a personal project I just worked on little pieces at a time. I started with a general premise that the data setup belongs in the routes; and the behavior and any session data belongs in the controller. For the view layer I prefer to use mostly templates w/ actions that can be handled by controller and also router (events bubble), if needed. And only if necessary, I use a view file, i.e. to specifically handle DOM events or work w/ 3rd party view code (disqus comments). Generally I tried something, wrote tests and if felt right kept the code; and at times when I know what I expect to do I’d write failing tests first. Even just the simple integration tests I wrote give me confidence that everything in the app is playing nice; so I can move on to another feature, then any regression testing is for the most part automated.