Infrastructure as Codeにおけるテスト駆動開発実践入門(上) - Qiita
Infrastructure as Codeにおけるコード開発にテスト駆動開発を導入する具体的な方法を全二回に分けて説明します。(上)ではIaCとは何か、テスト駆動開発とは何かについて概要を説明します。 Infrastructure as Codeにおけるテスト駆動開発実践入門(下)はこちら はじめに クラウド/コンテナ技術の登場により、ITインフラは頻繁に作っては捨てられる時代になりました。このような時代において、ITインフラの構成管理を従来通り手動で行うことは不可能です。なぜなら次のような事態が起こるからです。 頻繁にITインフラの構成が変わるため、手動で構成管理すると管理コストが膨大になる 管理表の反映し忘れにより、管理表に記載されているITインフラの構成と実際のITインフラの構成が乖離する そこで近年Infrastructure as Code(IaC)という技術が注目を集めていま
気負わず普通にテストしよう
はじめに これはシステムエンジニア Advent Calendar 2016の22日目の記事です。 色んなプロジェクトでのテスト体験や自分で学んだことをもとに、ポエムを書きます。 言いたいこと 普通にテストをこなそう 面倒だと感じたら、テストの設計か作業プロセスに問題があるから見直そう テストでは検証したいことを決めて、それに集中しよう ソフトウェアテストについての知識はざっと知っておこう 前提 本来はSIの現場で考えた場合、 UAT(受け入れテスト)やST(システムテスト)などにも言及すべきかもしれませんが、 あくまで僕個人という開発者目線なのでUT、ITが中心の内容になっています。 なんで作業が捗らないんだろう？ Javaを用いた金融系の業務システムをつくっているある日でした。 自分の作業がなんか思ったように進まないなぁということに気づきました。 「何に時間を使っているんだろう？」 な
ユニットテストの実行環境を用意して Visual Studio Code のエクステンションを快適に TDD する - Qiita
こんにちは @ryu1kn です。これは Visual Studio Code Advent Calendar 2016 の２日目の記事です。 Visual Studio Code (以下 VS Code) はバージョンが１に届いた頃からメインで使うようになりました。以降いくつかエクステンションを書いたのですが、今回はそれらのエクステンション開発時に必要だったユニットテストの環境準備について書きます。 TL;DR エクステンション生成時についてくるテストの実行環境は VS Code の全 API が使えるインテグレーションテスト用のものであり、起動が遅く TDD でのユニットテストには向かない コマンドラインから手早くユニットテストを実行できるようにしておくと快適に TDD できる VS Code の API を提供する vscode モジュールは、エディタ上で実行する時とコマンドラインか
ふつうのユニットテストのための７つのルール - ブログなんだよもん
最近、久しぶりにコードレビューをすることが増えたのですが、UnitTestのコードを見るとヒドイ部分が多く残念な気持ちになることもあります。 原因のひとつとして、プロダクトコードと違いテストの書き方をあまり書き方を明文化してなかったのが悪かったなと思い、とりあえず明文化してみました。 今回は、命名規則とかそのレベルまではいかず「ユニットテストかくあるべし」ってところまでをまとめます。正直、これ守ってくれたらあとは好みの世界もあるしね。 追記： テクニカルな部分も最低限ですがQiitaに記載しました。 qiita.com 追記： もうちょっと大上段の規約に関してもまとめてみました。 koduki.hatenablog.com 前提 ここではユニットテストを関数レベルのテストをJUnitのような自動テストツールで取り扱う場合に限定します。 また、Mavenでビルド時は常にテストを回すことを想定
ReactでTDD（テスト駆動開発）を始めよう : 環境構築からテスト作成、機能実装までの詳解ガイド | POSTD
最小限の設定のTDD手法を使い、「何をテストすべきか？」から、よくある落とし穴の避け方まで、Reactコンポーネントをテストする方法を学びましょう。 導入 まず、 React を触ったことがあり、更にはいくつかのテストも書いた経験があるとしましょう。それでも、コンポーネントをどうテストするのが最善なのか、よく分からないかもしれません。どこから始めるのでしょう。具体的には何をテストすればよいのでしょうか。 いくつかのReactコンポーネントは簡潔過ぎて、そもそもテストが必要なのかすらはっきりしません。 AngularからReactに乗り換えた 人なら、テストには愛憎のような思いがあるかもしれません。 確かに Angular にはテストを支援するツールがたくさんありますが、同時にテストを書くのが難しくなる可能性があります。冗長ながら省略できない定型コードが多々ある上、 $digest の呼び出
AnsibleTDD環境をtest-kitchen, serverspec, Dockerで作る(2015年10月版) - Qiita
これはtest-kitchen, serverspec, DockerをつかってAnsibleのテスト駆動開発を行う環境を構築する手順です。 Ubuntu14,CentOS7でApache2をインストールし、サービスを起動し、ブート時のサービス自動起動を設定するベストプラクティス構成1のAnsible playbookを例として取りあげます。 この記事の目標 AnsibleのTDD環境として、test-kitchenで次のことが出来る環境を作ります。 Docker上にUbuntu14, CentOS7のコンテナを立ち上げ 各コンテナをAnsibleでプロビジョニング 各コンテナのプロビジョニング結果をServerspecで検証 前提条件等 この記事の前提条件は以下のとおりです。 作成するAnsible playbookの構成はベストプラクティスのディレクトリレイアウトに従う1 作業環境は
test-kitchenでインフラのTDDに挑戦[Rails/nginx/MySQL/rbenv]
これまでVagrantやChefをつかってインフラのコード化を勉強してきましたが、今回はさらに一歩進めてServerspecを使ったインフラのテストと、『test-kitchen』を使ったTDDにチャレンしてみました！ 慣れてくるとtest-kitchenのコマンドで設定をやり直し => インフラのテストがソースコードを書くような感覚で、インフラを構築できるのがすごく心地良かったです。 ようやくですが、localのvagrantと『AWS EC2』、『Digital Ocean』に対応しました。コマンドひとつでChefを適用したり、Serverspecでリモートの環境をテストできます！ (05-02 08:35) Rubyサーバ・デプロイまでのチェックリストを追加 🐝 今回のソースコードVagrant/Digital Ocean/AWS EC2上にnginx/MySQL/rbenv/Ru
![test-kitchenでインフラのTDDに挑戦[Rails/nginx/MySQL/rbenv]](https://cdn-ak-scissors.b.st-hatena.com/image/square/c2ea7e72d0d7f3ba6c237909f321e67ffbdaa24e/height=288;version=1;width=512/https%3A%2F%2Fmorizyun.github.io%2Fimg%2Fog_image.png)
React TDD Example: Unit Testing and Building a React Component with Jest, Gulp and React Test Utils
ReactJs has attained lot of momentum since its initial release in 2013, and became the best JavaScript library for developing rich UI interface. React also popularized different concepts like Virtual DOM, Uni-directional data flow and Componentization in the front-end community. As of today, React has more than 20,000 stars in Github repo, and actively maintained by the Facebook team. Update Feb 9
Using TDD with React.js
A walkthrough of the Test Driven Development (TDD) process for testing React.js components with Jest from requirements to passing tests.James Burnett I write software for fun and profit. At the moment, I'm doing front-end web development because it is fun. Test Driven Development (TDD) is a very powerful and popular development methodology. Testing React.js components is most easily accomplished w
Test Drive Your Dockerfiles with RSpec and ServerSpec
Docker, a portable, lightweight runtime and packaging tool, is all the rage these days. It’s hard to go to any sort of tech meetup without overhearing people gushing to each other about how cool it is. I’d written some Dockerfiles but wanted to start test driving them. It’s actually fairly straightforward using RSpec and ServerSpec. Here’s how to TDD a Dockerfile that installs Node on Ubuntu. Star
テストをテストする方法-ミューテーションテスト- #gadvent - うさぎ組
はじめに これはG* Advent Calendarの12日目の記事です。今日はミューテーションテストについて書きます。明日はid:nobusue さんです。 概要 PITというツールの紹介です。「Javaプロダクトコードを機械的に変更してからテストを実行したときに、テストはそれを検知できるのか？」ということを調べてくれるツールで、SpockのテストやGradleからの実行に対応しています。 ミューテーションテスト ミューテーションテストとはざっくりと言えば「プロダクトコードを変更したなら、その振る舞いも変わるはず。テストはその変更された振る舞いを網羅できているかを調べる」というテストです。 対象規模が小さければ手動で毎回やってもいいわけですけど、ツール化されていると楽なことこの上ないです。ということで、今回はJavaプロダクトコードをミューテートするライブラリであるPITについて紹介しま
使えるRSpec入門・その3「ゼロからわかるモック（mock）を使ったテストの書き方」 - Qiita
はじめに みなさんこんにちは！ この記事は「必要最小限の努力で最大限実戦で使える知識を提供するRSpec入門記事」、略して「使えるRSpec入門」の第3回です。 今回はRSpecのモックを使ったテストについて説明します。 これまでモックを全く使ったことがない人でもわかるように丁寧に説明していくつもりです。 また、これまでの回と同様、個人的に使用頻度が低いと思っている内容についてはバッサリ説明を省きます。 ただし、第1回や第2回に比べるとテストコードが少し複雑になって、仕組みや動きを想像するのがちょっと難しいかもしれません。 ぱっと頭に入ってこない場合はじっくり本文を読んだり、実際に自分で写経しながらコードを動かしたりするなどして、少し時間をかけながら理解するようにしてください。 今回は以下のような内容を説明します。 モックの基本的な使い方 モックを使った検証 モックでわざとエラーを発生させ
プレイブック -開発- | POSTD
thoughtbotはWebとモバイルアプリを開発するWebコンサルティング会社。Railsの有名プラグインであるPaperclipやFactory Girlなどのオープンソースプロジェクトや、自社プロダクト（hound、Upcase）も開発している。ボストンをベースに、サンフランシスコ、デンバー、ニューヨーク、フィラデルフィア、ローリー、ストックホルムにオフィスを持っている。 開発手法の大半は、まずKent Beckの有名な著書『Extreme Programming Explained: Embrace Change』（邦訳『XPエクストリーム・プログラミング入門』）、そしてGerald Weinbergの『The Psychology of Computer Programming』（邦訳『プログラミングの心理学』）で詳細に述べられています。それらを試したところ、多くの手法を開発中に
TDDを諦めることと、RSpecをやめること - 高柴ラボ
2014-10-17 TDDを諦めることと、RSpecをやめること Ruby on Rails Ruby RSpec 開発手法 最近Web上でも仕事場でも、RSpecをやめて別のテストフレームワークに変えようと思っている……みたいな話をちょくちょく見聞きするようになった。僕がRuby on Railsで開発を始めた2012年8月当時、すでにRSpecはテストフレームワークのデファクトと言ってよかった。一斉を風靡したRSpecが、なぜ今見直され始めているのか。 きっかけになったのは今年4月の、Rails作者であるDavid Heinemeier Hansson(以下DHH)によるTDD is dead発言だと思う。 5月にはこの発言によるTDDへの風評被害を重く見たKent Beck*1が、レフリーにMartin Fowler*2を迎え、DHHと相対するドリームマッチが開催された。この会談の
テスト駆動開発（TDD）はもう終わっているのか？ Part 1 | POSTD
後編を公開しました（2014/10/8） これは、テスト駆動開発（TDD）とTDDがソフトウェア設計に与える影響についてKent Beck、David Heinemeier Hansson、および著者の3人で行った一連のディスカッションの議事録です。 ディスカッションに至った経緯 あるセンセーショナルな発言とブログ記事が発端となり、お互いの見解と経験について理解を深める目的で、話し合いが持たれました。 この会話のきっかけとなったのは、 DavidがRailsConfで行った基調演説です。 彼はRailsコミュニティでTDDおよびユニットテストへの不満を表明しました。 程なくして、彼はいくつかのブログ記事を公開しましたが、そのうちの最初の記事で “TDDは終わった” と宣言したのです。 それから2～3日後、Davidのその後の記事について私がタイプミスの修正を送ったところ、 Davidは彼の
Testing on the Toilet: Test Behaviors, Not Methods
Thanks as a QAE, I was so tempted to write all my validations in a single test esp when there is a continous flow happening. Now that temptations has eased. Howeve this because more challenging when we write UI Tests with a lot of inputs before it even lands on the page to test. Where is the line to be drawn before going crazy and write automation tests for each test case vs combining all tests in
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
開発効率を上げるテスト設計
GitHub - quangv/shirt-sizes: React+Redux, shirt size app (Bing API dead)
GitHub - donnemartin/interactive-coding-challenges: 120+ interactive Python coding interview challenges (algorithms and data structures). Includes Anki flashcards.
Test Yourself - テストを書くと何がどう変わるか
