https://geechs-magazine.com/tag/tech/20160114
177bdf6352de463fdc87
経験ゼロでもできるプログラミング現場の単体テストを読んだので、そのまとめ はじめに 著者曰く、 初めて導入する単体テストの指南書 を目指した一冊。 単体テストを書いたことが無かったり、書いたことがあっても書き方の方針が定まっていない人にはおすすめの本。 逆に既にバリバリテストコードを書いてる人に、再確認的な内容になるかも。 単体テストについて基礎知識 アプリケーション開発では設計に時間がかかりすぎて、テストに時間をかけられないことがある。 致命的な障害発生する可能性がある。 とはいえすべてを想定してテストを実施することはできない。 テストケースを絞る必要がある 各テストフェーズの礎となる単体テストが重要になる 高品質なシステム ユーザーを満足させ、不安や不満をいだかせないこと システムエラー：データの破損などの心配が生まれる 応答が遅い：いらいら・二度と使わなくなる まとめてテストはダメ
単体テスト（画面単位のテスト）がクソらしいので思ったことを書いてみる - うさぎ組
なんか2週間くらいずっと画面単位のテストを単体テストと呼んで、手動テストをする現場についていろいろ文句がSNSで流れていた。それについて思うことをバカスカ書く。 これは、誰かを批難したいわけでもなく、ただの感想である。言うなれば街の風景をみたときの日記だ。そうだよ。これは日記だよ？ 要約 だいたいの話は僕が2,3年前にTwitterで言いまくった単体テスト/結合テストなんて存在しない - Togetterまとめに似ていると思ったけど、僕の狭い観測範囲では生産的な結論を迎えずに文句の固まりで終わって、こう非常にあーあっていう気持ちが残った。 あと、観測結果として 同僚や上司に加えてkyon_mmに「なぜその手法でテストをしたいの？ねぇ？なんで？」って聞かれても答えられるか。が相手を評価する目安だと僕自身が自覚した。 というのが大きかった。 単体テスト まず、最初に思ったのはTwitterで文
テストがうまくいかないプロジェクトに捧ぐ、正しいテストの考え方 - Qiita
この記事の対象者 プロジェクトでテストを書いている。(書いたことある) テストが重要らしい事は知っているが、テストの恩恵をそこまで実感できていない。 結局手動テストに依存したバグフィックスをしている。 はじめに 私はテストの設計手法、実装に関する知識は多く持っていましたが、知らなかったことはテストの考え方でした。 テストが重要らしいことを知っている人は多いと思います。 しかし、実際に恩恵を実感できていない人もいると思います。 事実、 テストが重要だと発信している人 と、 テストが重要らしいことを知っている人がいます。 後者の人は、とりあえずテストを書く事ができます。しかし、テストに時間を割く割りに、最終的には手動テストでバグを発見することに依存している事も多いかなと感じます。 世間ではテスト書くのが当たり前、テストは重要！という風潮であるのに、何故テストが重要であると実感できないのでしょう
単体テストについて - Qiita
一月ほど前に「テスト不要論」なるものが炎上しており、思うところがあったので、少しまとめてみました。 ご存じのとおり、テストにはブラックボックステスト・ホワイトボックステストがあります。 しかし、この二つの目的が大きく違うということを知らない人が多いのではないでしょうか。 ブラックボックステスト ブラックボックステストはコード実装者以外が行うべきものです。 コード実装者は書いてしまった以上ブラックボックスにはできませんし、 テストファストであっても頭の中にこれから書く実装が出来上がっていれば同様です。 ブラックボックステストは設計書通り（設計者の意図通り）にかけているのかという観点でテストし、品質指標とします。 別に設計書通りに書けば品質は高いなんて保障はないので、これを時間の無駄と考える人がある程度いるのではないかと思います。 しかし、プログラマの義務はブラックボックステストではなくホワイ
フロントエンドの負債と向き合う - mizchi's blog
某所で書いたものを公開用に書き直したもの 前提 フロントエンドでTDDは難しい、というかほぼ不可能である。なぜなら事前に副作用をデータとして表現できるか不明だからだ。たとえばあなたのプロダクトの画面の何処かにボタンを追加するために、その内部表現を事前に思い浮かべることが可能だろうか？ react-redux などのFluxフレームワークは如何に副作用をアクションとして表現することで、テスト・デバッグのための情報を残すか、という視点で発展してきた側面がある。あの冗長なアクション定義は、全てデバッグのために書いていると言っても、過言ではない。それすら「Textは文字がある」といったトートロジーなデータになりがち。 フロントエンドの現実的な単体テストは、他の開発者のために、自分が書いたコードの要求を満たしているか検知する手段として、防衛的にテストアフターしておく。これぐらいしか現実的な手法がない
Shows
AI is suddenly everywhere. Do you need to go and get a shiny machine learning degree to remain competitive? John Maeda says not to worry. He’ll show you how to cook delicious dishes into your coding repertoire with his new show - Mr. Maeda’s Cozy AI Kitchen. Find out how you can use GitHub Copilot, an add-on that is powered by AI, to get helpful suggestions when writing code or documentation. This
AngularでFormのCustom Validation - Carpe Diem
概要 AngularでのFormのカスタムバリデーションには主に以下の方法があります。 Directiveで用意する ビルトインのValidatorsのような関数を用意する 今回は後者の実装例を紹介します。 validationロジック 今回はクレジットカードの簡易チェックをするvalidatorを導入します。 クレジットカードの番号はLuhnアルゴリズムに基づいています。 これによってわざわざサーバ通信を挟む前に、入力ミスなどによる不正な番号を弾くことができます。 環境 Angular 2.4.5 angular-cli 1.0.0-beta.28.3 成果物 今回の完成形は以下 github.com 実装 import { AbstractControl } from '@angular/forms'; export class CreditCardValidator { static
Angular入門: Component/ServiceをTestまで含めて試す - Qiita
<p>Counter</p> <p>Point: {{point}}</p> <button (click)="increment(3)">Increment 3</button> <button (click)="decrement(2)">Decrement 2</button> import { Component } from '@angular/core'; import {CounterService} from './services/counter.service'; @Component({ selector: 'app-root', templateUrl: './app.component.html', styleUrls: ['./app.component.scss'] }) export class AppComponent { point: number; c
Angular CLIによるAngular2入門 / Angular2アプリを爆速開発 - Qiita
ついにリリースされましたね、Angular2! Angular2にはCLI(command line interface)の開発環境が整えられており、雛形の自動生成、更新ファイルを自動ロードするなど、爆速な開発が可能になっていることをご存知でしょうか。 このAngular CLIを導入するだけで、様々な開発環境が一気に整います。そのため、gulpだgruntだ、TypeScriptだと様々な環境を整える必要があった今までの開発スタイルが一気に変わる可能性があります。 以下では、Angular CLIを使って共通ロジック[MessageService]からテキストを取得して、そのテキスト表示する画面部品、[HelloComponent]を持ったアプリを作りたいと思います。サービスやコンポーネントを使うのでAngularでの開発のおよその骨格を感じ取っていただけると思います。 では、Angul
Marginalia
2023 2023-11-22 記事中のURLプレビューを実装した (Cloudflare Pages Functions) #Cloudflare #雑記 2023-11-18 『スタッフエンジニア』読後メモ #読書 #雑記 2023-11-16 アドベントカレンダーに参加してほしい #コミュニティ #雑記 2023-11-13 プロジェクトはキックオフが9割 #雑記 2023-11-12 Angular SSR on Docker #Angular #Docker 2023-10-24 チームを対象として見る #チーム #雑記 2023-10-23 自分のアイコンの缶バッジを作ると便利 #雑記 2023-10-18 Angular MatSuffixをフォーカス中だけ表示する #Angular #Angular Material #tailwindcss 2023-10-16 『経営学
フロントエンドのテストを Karma + Docker を使って実行する | スマホ神 – JavaScript 受託開発 –
テストの実行環境はDockerで作ると、環境をアレコレする必要がなくて便利です。 フロントエンドのテスト環境も簡単に建てられて、簡単に捨てられると便利なはずです。 というわけで Docker を使って Karma の環境を構築してみます。 必要なもの docker docker-compose npm Dockerfile まずは Dockerfile を用意します。コンテナ内で必要なのは xvfb chrome firefox node npm karma あたりです。 FROM ubuntu:14.04 RUN apt-get install -y wget && \ wget -q -O - https://dl-ssl.google.com/linux/linux_signing_key.pub | apt-key add - && \ echo "deb http://dl.go
テスト自動化研究会 - テスト自動化の8原則
1. 手動テストはなくならない 2. 手動でおこなって効果のないテストを自動化しても無駄である 3. 自動テストは書いたことしかテストしない 4. テスト自動化の効用はコスト削減だけではない 5. 自動テストシステムの開発は継続的におこなうものである 6. 自動化検討はプロジェクト初期から 7. 自動テストで新種のバグが見つかることは稀である 8. テスト結果分析という新たなタスクが生まれる これらの原則は、どのようなドメイン、プロセス、ツールの現場におけるテスト自動化であっても共通して言える、テスト自動化に取り組む前に留意しておくべきことがら＝原則を、テスト自動化研究会のメンバーによる議論のうえ、絞り込んだものです。これからテスト自動化に取り組まれる方、現在取り組まれている方、これから見直しをされたい方にご参考いただければ幸いです。 解説 1. 手動テストはなくならない ユーザビリティテ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Redirecting
New angular-cli project failing/time-out on Circle-Ci
Angular 2.0.0 - Testing " imported by the module 'DynamicTestModule' "
Unexpected value 'DecoratorFactory' imported by the module 'DynamicTestModule' - karma-jasmine
Angular 2 + ng test: 'X' is not a known component
angular-cli tests fail after creating shared module
CircleCIでLintとTestをParallel実行 - Qiita
