RustプロジェクトのCI設定 - テスト実行からカバレッジ計測まで - Qiita
Rustを使ったプロジェクトのCI(Continuous Integration)設定を調べてみた結果、ただ単にテストを実行する以上に色々便利な設定があったのでご紹介したいと思います。 また、本記事ではRustプロジェクトのリポジトリをGitHub上で管理していることを前提としています。 以下、テスト・ベンチマークの実行、ドキュメントの自動生成、コードカバレッジの計測について順に記載していきます。 1. テスト・ベンチマークの実行 テストやベンチマークの自動実行にはTravis CIを利用しました。 Travis CIはデフォルトでRustをサポートしていますので、ガイドに従って普通に設定すればCI環境が動作し始めますが、いくつか気をつけたほうが良い部分をまとめます。 コンパイラの選択 Rustのコンパイラは安定版であるStableチャネルだけでなく、BetaチャネルとNightlyチャネ
BrowserStack と Karma でクロスブラウザテスト環境を作る - Qiita
module.exports = function(config) { config.set({ browserStack: { username: "<your-username>", accessKey: "<your-token>" }, // base path that will be used to resolve all patterns (eg. files, exclude) basePath: "", // frameworks to use // available frameworks: https://npmjs.org/browse/keyword/karma-adapter frameworks: ["mocha"], // list of files / patterns to load in the browser files: [ "browser-sp
TypeScript + webpack + Karma + Mocha + Power Assertでテストを行う際の諸々の設定ファイル - Qiita
TypeScript + webpack + Karma + Mocha + Power Assertでテストを行う時の諸々の設定ファイル 最近、TypeScriptでコードを書いて、モジュールバンドラにwebpack、テストランナーにkarma、テスティングフレームワークにmocha、アサーションライブラリにPower Assertを使用したユニットテストを書いた その際に、諸々のツールが複雑で、設定ファイルの記述も大変だったので、ここで設定ファイルについてのメモを残しておこうと思う ※現段階では、設定ファイル自体にメモを書いただけです、後で個々の説明を書くかもしれません package.json まずはこれがないと始まらないですよね { // パッケージの名前 "name": "パッケージ名", // パッケージのバージョン "version": "1.0.0", // パッケージの説
[riot 習作]riotでAPIテストツールを作ってみよう - Qiita
皆さん、こんにちは 最近のJavaScriptのフロントサイドのフレームワークもしくはアーキテクチャは、AngularとReactJSが主流となっているように感じますが、一方で、vue.jsやriot.jsのような大企業がバックにないようなフレームワークにも光が当たってきています。 個人的にはどれがいいというよりは、作成するアプリの性質に応じて使い分けるのがいいんじゃないかなぁと思いますが、弊社内ではAngular, ReactJS, vue.jsを推す人はいるのですが、riot.jsを推す人がいなかったので、じゃあ私がやっちゃおうということでやりました。 TODOアプリとかはすでに公式サイトにあるので、ここではAPIをテストするためのツール作成を通して、riot.jsの挙動を調べてみましょう。 ちなみに今回のはriot 3.0を使っているのでそれ以前のバージョンを使っている場合は、動かな
![[riot 習作]riotでAPIテストツールを作ってみよう - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/a70c9cadc8a1855e52d9609dd162d55fb78c9aba/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Farticle-ogp-background-412672c5f0600ab9a64263b751f1bc81.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTk3MiZoPTM3OCZ0eHQ9JTVCcmlvdCUyMCVFNyVCRiU5MiVFNCVCRCU5QyU1RHJpb3QlRTMlODElQTdBUEklRTMlODMlODYlRTMlODIlQjklRTMlODMlODglRTMlODMlODQlRTMlODMlQkMlRTMlODMlQUIlRTMlODIlOTIlRTQlQkQlOUMlRTMlODElQTMlRTMlODElQTYlRTMlODElQkYlRTMlODIlODglRTMlODElODYmdHh0LWFsaWduPWxlZnQlMkN0b3AmdHh0LWNvbG9yPSUyMzIxMjEyMSZ0eHQtZm9udD1IaXJhZ2lubyUyMFNhbnMlMjBXNiZ0eHQtc2l6ZT01NiZzPTc4MjFjMDNjOWE3MmJmMDU2MDQ2OWJlNzJkZmY5YzZj%26mark-x%3D142%26mark-y%3D57%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZoPTc2Jnc9NzcwJnR4dD0lNDBuaWlzYW4tdG9reW8mdHh0LWNvbG9yPSUyMzIxMjEyMSZ0eHQtZm9udD1IaXJhZ2lubyUyMFNhbnMlMjBXNiZ0eHQtc2l6ZT0zNiZ0eHQtYWxpZ249bGVmdCUyQ3RvcCZzPThhOTk3ZjJhY2ExYTc2ODBiMTE0ZWUwZjJhODg4NzE1%26blend-x%3D142%26blend-y%3D436%26blend-mode%3Dnormal%26txt64%3DaW4g5qCq5byP5Lya56S-Uk9YWO-8iOaXp--8muagquW8j-S8muekvlNDT1VURVLvvIk%26txt-width%3D770%26txt-clip%3Dend%252Cellipsis%26txt-color%3D%2523212121%26txt-font%3DHiragino%2520Sans%2520W6%26txt-size%3D36%26txt-x%3D156%26txt-y%3D536%26s%3D0e10b90da59b04ae41b145cae3d51416)
JavaScriptのテスト環境構築(Mocha + power-assert + Karma + babel + webpack) - Qiita
この記事は、初めてJavaScriptのテスト環境を作ってみたおじさんによる、これからJavaScriptのテストを書いていきたいけど、登場人物が多すぎてなにやらめんどくさそうと思っている方に向けた記事兼備忘録です。 初めてのJavaScriptテスト環境構築で一応公式ドキュメントに目を通したけど英語の意味をちゃんと読み取れておらず、ツールやライブラリの理解や使い方が間違っている場合がありますのでアドバイスいただけると幸いです。 各テストツールやライブラリの紹介 JavaScriptのテスト環境を構築するときの一つ目の壁がツールやライブラリがたくさん出てきて、どれを使っていいかわからない/それぞれの役割がわからないことだと思う。 なので、まずはJavaScriptのテスト環境についてググったときに出てくる最近使われてそうな各ツールやライブラリの役割をすごく雑に紹介します。 テストフレームワ
database_cleaner transactionの設定 - Qiita
database_cleanerの設定(transactionが使える場合) 背景 database_cleanerでテスト前後のDBの消去をしています。 database_cleanerには消去の方法として以下の２つがあります - truncation - transaction transactionはtruncationに比べ、DBに制約はあるものの、 truncateするのではなくtransactionをrollbackするだけなので早いです。 詳しくは公式のページを見てください。 https://github.com/bmabey/database_cleaner 自分の対象とするシステムはmysqlを使っているので、 transactionが使えました。 実際の設定方法 Guard+spork+rspecでまわしている場合、 Spork.preforkの中に以下のように追記すれ
PHPStorm で PHPUnit のテストをステップ実行する - Qiita
概要 PHP で PHPUnit のテストがうまく通らず、PHPStorm でステップ実行したくなることがたまにあります。 しかしながら、PHPStorm の PHP Remote Debug はブラウザ経由でないと、動きません。 と、思っていましたが PHPStorm でやれる方法が判ったので設定方法を共有します。 なので、無理やり画面を作って、PHPUnit を実行する方法を取ったら、まあ上手くいったので覚書ついでに共有してみます。 (2016--216 k-hottaさんからの指摘でさらに良い方法にたどり着いたので修正しました。) さらに良い方法をご存知の方がいらっしゃいましたら是非コメントください。 前提環境 PHPStorm を使っている。 vagrant を使っており、 php はゲストサーバ側にある。 （つまりリモートデバッグは可能。） テストしたい部分には Web 経由で表
Angular入門: Component/ServiceをTestまで含めて試す - Qiita
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; constructor(private counterService: CounterService) { this.point = counterService.point.getValue(); counterService.point.subscribe((v) => this.p
DockerでXDebug使ってPHPデバッグする際はremote_connect_backが使えない - Qiita
XDebugを使ってPHPのデバッグをする際、設定方法には2つある。 remote_hostをホストPCのIPアドレスに設定する remote_connect_backをtrueにする remote_connect_backを使えばホストPCのIPを入力せずとも、ホストPCとの連携が簡単に出来る。 If enabled, the xdebug.remote_host setting is ignored and Xdebug will try to connect to the client that made the HTTP request. https://xdebug.org/docs/all_settings#remote_connect_back ところが、Docker上にインストールしたXDebugとの連携の場合は、こうはいかないらしく、remote_hostを設定しないと動
iOS アプリの Unit Test - Swift 編 - Qiita
以前、 Objective-C と OCMock についての記事を書きましたが、今回は Swift について書いていきます。 準備 Xcode の使い方やプロジェクトの設定は Objective-C と基本的に同じなのでそちらを参照してください。 このように Project > Build Settings > Defines Module を YES に設定します。 テストコード 標準の XCTest Framework を使う場合は書き方が Swift になるだけで、Objective-C とほとんど同じです。 違うところは、Objective-C の場合はテストに関連するクラスを個別に import しなければならなかったのが、@testable import sample のようにテスト対象のターケッドを指定するだけでよくなります。 import XCTest @testable
Reactのテストを mocha + nyc から Jestにしてみる - Qiita
{ "test": "NODE_ENV=test mocha test/", "coverage": "nyc -c npm test" } /srcにソースディレクトリ /testにテストディレクトリ MISC jsdom-global使って色々小細工していた。 mocha -> jestにするモチベーション 興味本位 Jestがv15.0.0でAutomockingを捨てて本気を出してきたのでちょっと使ってみたかった気持ち Railsプロジェクトにjavascriptプロジェクトを混ぜようとしたとき、mochaのテストディレクトリに悩んでしまうぐらいなら、Jestのテストフでやってみようかと思った jestでは、/srcなどのコードに対して、/src/__tests__というディレクトリを作るか、some.test.jsという名前をつけるのがデフォルト設定になっている。 mochaでも
Bitbucket + Werckerを使ってプライベートリポジトリで無料CI（PHPUnit, MySQL) - Qiita
PHPでWebアプリを作っています． ケチなので全部タダでやりたくてbitbucketを使っています． 今回，CIをやりたくなったのでタダでできるCIサービスを探したらWerckerが良さそうとのことだったので使ってみました． PHP用の情報が少なくて苦労しました（最新版の公式ドキュメントの言語別ページにはそもそもphpが無かった）． 構成 メインのアプリはprivateで開発したいのでbitbucketのプライベートリポジトリを使いつつ， 一部のコードをライブラリ化してgithubで公開しています． なので， メインのリポジトリはBitbucketのプライベートリポジトリ submoduleとしてgithubのパブリックリポジトリを参照している という構成になっています． また，PHPを使っていて，フレームワークはFuelPHP，PHPUnit用のテストコードがあります．DBはMySQL
RSpecのletを使うのはどんなときか？（翻訳） - Qiita
# インスタンス変数を使う場合 before do @user = User.new(name: 'Taro', email: 'taro@example.com') end it 'is valid' do expect(@user).to be_valid end # letを使う場合 let(:user) { User.new(name: 'Taro', email: 'taro@example.com') } it 'is valid' do expect(user).to be_valid end RSpecを使い慣れている人であれば、おそらくletを使うことが多いと思いますが、初心者の人には違いやメリットがよくわからないと思います。 また、使い慣れている人であっても具体的な違いをぱっと即答できる人は少ないんじゃないでしょうか？ ネットを調べていたところ、Stack Overfl
PhantomJS で Content-Disposition: attachment なレスポンスを取得する方法 - Qiita
はじめに とあるサイトに定期的にログインして利用履歴のCSVを取ってくるというプログラムを AppleScript + Safariで書いていたがいちいち Safari が起動してめんどくさいので、PhantomJS で書きなおすことにした。 さっそく PhantomJS の最新版(1.9.2) をインストールして、スクリプトを書いた。コードは下記のとおりである(簡易化してある)。 page = (require 'webpage').create() callbacks = [ -> # ログイン画面の処理 page.evaluate -> document.getElementById('user').value = 'user' document.getElementById('pass').value = 'pass' e = document.createEvent('Mouse
Minitest でテスト、Rails のテスト (その1) - Qiita
だいたいぼくは Rails のプロジェクトではテストフレームワークとして Minitest を使っているのですが、だいたい「RSpec しか書いたことなくて Minitest わかんねー」という苦情をいただくので、なんとなく Minitest について、なんか使い方だとか、書き方のコツだとか、なんかそんなようなやつをまとめていこうと思います。 内容は「Minitest Cookbook」の「Rails Recipes」の章を思いっきり参考にさせてもらっています。なので Minitest 自体の説明は少なくて Rails のテストに特化した内容となっています。この本はほとんど唯一の Minitest 本だと思うし、ここで紹介する Rails 絡み以外の部分も良い内容なので読んでおくといいでしょう (そこそこ高いけど) 。 ちなみにこれは「その1」で、まだまだ続く予定ですがいつ書くかは未定です
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Xamarin.Formsのソースコードをビルドしてテストを実行してみた - Qiita
AngularとZone.jsとテストの話 - Qiita
RSpecのフォーマッターの出力結果を任意のデータストアに保存できるgem rspec-storageを作った - Qiita
モックオブジェクトをより便利にする (Try! Swift2017) - Qiita
Rails RSpecの基本 ~Controller編~ - Qiita
