To run browser tests, open a new Terminal window or tab and change to the project directory, then tell gulp to start the tests:
gulp build
gulp test:acceptance ( tox -e acceptance can be run as well )
<script type="text/javascript"> | |
var c=0; | |
var t; | |
var timer_is_on=0; | |
function timedCount() | |
{ | |
if (c<50) | |
{ |
var scripts = []; | |
var src; | |
var script; | |
var pendingScripts = []; | |
var firstScript = document.scripts[0]; | |
function stateChange() { | |
var pendingScript; | |
while (pendingScripts[0] && pendingScripts[0].readyState == 'loaded') { | |
pendingScript = pendingScripts.shift(); |
Decorative images don’t add information to the content of a page. For example, the information provided by the image might already be given using adjacent text, or the image might be included to make the website more visually attractive. [1]
Images may be deemed decorative when they are :
# Decorative images | |
Decorative images don’t add information to the content of a page. For example, the information provided by the image might already be given using adjacent text, or the image might be included to make the website more visually attractive. [1] | |
Images may be deemed decorative when they are : | |
- Visual styling such as borders, spacers, and corners; | |
- Supplementary to link text to improve its appearance or increase the clickable area; | |
- Illustrative of adjacent text but not contributing information (“eye-candy”); |
https://www.consumerfinance.gov/static/fonts/cf-icons.b3dc2065fce0.ttf | |
https://www.consumerfinance.gov/static/fonts/cf-icons.c4e11355d0bd.woff |
Our testing philosopy and policy is explained in the following documents:
https://github.com/cfpb/cfgov-refresh/blob/master/TEST.md
https://github.com/cfpb/front-end/blob/master/testing.md
I would only add that our Acceptance tests should focus on testing functionality and dom structure. Testing content becomes tricky because it's constantly changing via the CMS or some other channel. This is demonstrated in the following example:
#Notes on Javascript Philosophy
We develop simple modules that adhere to the CommonJS spec and FIRST principles.
Our decision to just rely upon vanilla Javascript was born out our desire to be lightweight and performant. This decision has resulted in a better understanding of how to construct applications, address cross browser issues, and performance tune on mobile. I want to stress that we weren't ideologically opposed to using other frameworks or libraries. We just made a decision based on project complexity and skill of the team.
#Notes on Frameworks
We opted not to use any frameworks; the application isn't a SPA (single page application) and we didn't think it's level of complexity warranted using one. This might be a mistake and it's worth revisiting this decision, now that we have migrated to Atomic design.
The pros / cons of that decision are as follows:
- Smaller builds and minimal markup ( JS, CSS, HTML). Many frameworks are bloated and
applications only use a small portion of their functionality / features.
I highly suggest reading http://www.ebaytechblog.com/2014/10/02/dont-build-pages-build-modules/. It encompasses exactly what we are trying to achieve by building components using atomic design. I also want to stress that our front-end atomic architecture is still evolving.
Our components are broken down into templates, organisms, molecules, and atoms. We opted not to use the page component, although it exists in atomic design. Our components are composed of HTML, CSS, and Javascript. If a component doesn’t have user interactions or require styling, then it won’t have an associated js and/or css file. We compose our atomic components as follows:
Prefixed with “a-” in CSS, Javascript, and HTML files.