InversifyJSで学ぶDI(Dependency Injection) - Qiita
はじめに DIコンテナ自体は特に目新しい技術ではありません。JavaScript界隈ではAngularJS 1.xやRequireJS(AMD)等はそれ自体がDIの仕組みを内包したライブラリです。 しかし、これらのDIは若干無理やりな実装方法を取っていた感があります12。これはJavaScriptでメタデータやAOPを適切に扱う機能が不足していたことが背景にあると考えているのですが、ここ1, 2年で言語側の状況も変化してきています。 具体的にはTypeScript 1.5からDecoratorsがサポートされたり、ES 2015にてリフレクションの仕様が追加されたりと、よりスマートなDIコンテナを実装するための基盤が整いつつあります。 そこで今日はInversifyJSという軽量JavaScript DIコンテナについて触れるとともに、最新のDI事情を見ていきたいと思います。 Invers
Sinon Tutorial: JavaScript Testing with Mocks, Spies & Stubs — SitePoint
Stay Relevant and Grow Your Career in TechPremium ResultsPublish articles on SitePointDaily curated jobsLearning PathsDiscounts to dev toolsStart Free Trial7 Day Free Trial. Cancel Anytime. One of the biggest stumbling blocks when writing unit tests is what to do when you have code that’s non-trivial. In real life projects, code often does all kinds of things that make testing hard. Ajax requests,
JSDocをランタイムassertに変換するBabelプラグインを書いた
JSDocをassertに変換するライブラリとそれを使ったBabelプラグインを書きました。 azu/babel-plugin-jsdoc-to-assert: Babel plugin for jsdoc-to-assert. azu/jsdoc-to-assert: JSDoc to assert ライブラリのjsdoc-to-assertの方は、JavaScript ASTのコメントからassertの文字列を作り出すだけのシンプルなものです。 実際に使う場合は、Babelのプラグインとしてbabel-plugin-jsdoc-to-assertを使い、コードを変換してランタイムassertを追加させます。 やっていることとしては、FlowTypeをランタイムチェックするbabel-plugin-typecheckのJSDoc版とも言えます。 babel-plugin-typechec
javascript-unit-testing-performance · Jest
Jest is running thousands of tests at Facebook at all times, either through continuous integration or invoked by engineers manually during development. This worked well for years even as the people working on Jest moved on to other projects within Facebook. As engineers added more and more tests though, we noticed the performance of Jest wasn't going to scale. Additionally, in the last year the Ja
GitHub - airbnb/mocha-wrap: Fluent pluggable interface for easily wrapping `describe` and `it` blocks in Mocha tests.
var wrap = require('mocha-wrap'); var expect = require('chai').expect; var mockWindow = { location: { href: 'test/url' } }; wrap().withGlobal('window', () => mockWindow).describe('mocked window', function () { it('is mocked', function () { expect(window).to.equal(mockWindow); }); it('has the right URL', function () { expect(window.location.href).to.equal('test/url'); }); }); var obj = { a: 1 }; wr
GitHub - bugthesystem/scientist.js: :microscope: A JavaScript interpretation of the Ruby library Scientist, a library for carefully refactoring critical paths.
import {Experiment, Result} from 'scientist.js'; import Permission from './permission'; import Model from './model'; class MyWidget { constructor() { this.model = new Model(); } allows(user) { var experiment = new Experiment("widget-permissions"); experiment.use(() => this.model.checkUser(user).valid); // old way experiment.try(() => user.can(Permission.Read, this.model)); // new way return experi
Release v1.0.0 · testem/testem
Install using npm install -g testem@1 Breaking #710 Testem bails now by default on global errors, you can disable this by setting bail_on_uncaught_error: false #706 Removed embedded test frameworks. Test frameworks are loaded from the internet now, when you need a custom version or just want no network dependency you can inject your own framework as you used too https://github.com/testem/testem/tr
textlintで文章カバレッジレポートを継続的に見ていく
以前、技術文書をソフトウェア開発する話でtextlintやGitBookを使って文書を開発する方法についてお話しました。 その時に、自然言語のチェックの自動化などはまだ色々考えられることがあるという話をしました。 文書のテストはまだまだ色々できることがある カバレッジを取るとかメトリクスを取るとか – まとめ1 | 技術文書をソフトウェア開発する話 そこで文章のカバレッジというものを考えて実装してみました。 textlintとコードカバレッジの仕組みを使ったものですが、こういうのをなんと呼べばいいのかよくわからなかったので、ここではとりあえず”文章カバレッジ”と読んでいます。 textlintは全ての文に対してLintを実行するので命令網羅と近い感じがします。 命令網羅（statement coverage：SC） コード内のすべての命令が少なくとも1回は実行されるようにテストを設計する。
Day 2: Testing React Applications
In this article we’re going to take a look at how we can test React applications. Typically applications built with a frontend framework are difficult to test; it’s tricky to emulate the actions of your users in testing, despite it being one of the most important things to test. If your tests can’t emulate what a user might do, it’s going to be tricky to have full confidence that your application
GitHub - unit-coverage/unit-coverage: Precise, powerful and fast JS Coverage tool
Coverage toolkit designed to collect coverage information separately for each test. Unlike most coverage tools, unit-coverage keeps connection between source file and its test file. For each source file coverage is beeing computed only when its tests are running. This ensures you have correct test coverage for each file beeing tested. For example you have file source.js and its test: source.test.j
Mocha + Chai.js unit testing for ES6 with Istanbul code coverage
Testing is very important for finding bugs, verifying the functionality and improving the general stability of a piece of software. Almost all (if not all) developers test their code in some way. One way to test would be to manually run the program and try out all the functions to see if everything is working as expected. Another (and better) way is to write automated tests that are run every time
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
JavaScriptテストの疑問、お答えします #frontrendJS
GitHub - bakkot/normalize-parser-test
GitHub - tusharmath/funjector: Dependency injection for functional paradigm
GitHub - parro-it/tape-async: A tiny wrapper around tape to simplify async testing.
Release v1.5.0 · testem/testem
GitHub - vinsonchuong/jasmine-es6: Helpers and overrides that augment Jasmine for use in an ES6+ environment
Redirecting
nds_8_reftest.pdf
GitHub - AriaMinaei/shapely: A simple runtime type checker for javascript supporting records and tagged unions
