忙しい研究者のためのテストコードとドキュメントの書き方 - Qiita
はじめに 「研究用のプログラムにもテストコードやドキュメント書いたほうがいいよね。」 「分かっちゃいるけど、そんな面倒なことやってられないよ。」 という研究者あるあるを解決すべく、僕が普段実践している開発スタイルを紹介します。 この開発スタイルのすごいところは： テストやドキュメントを一切書かない場合と比べて 追加の工数がほぼゼロ。 普通にコーディングしているだけで、いつのまにかテストコードとドキュメントまでできあがっている。 実装、コメント、テスト、ドキュメントが自然に同期するので、保守しやすい。 Pythonを例に紹介しますが、コメント内にテストを書けるツールと、コメントからドキュメントを生成できるツールをもつ言語ならばどれにでも応用できるはずです。 この開発スタイルに至った背景 ソフトウェア開発において、テストコードやドキュメントを整備することでプログラムの品質が向上することは広く知
JavaScriptで(そしてどんな言語でも同じで)世界一簡単なテストフレームワークを作って使おう - Qiita
はじめに どんな言語でもテストコードは簡単につくれます。 [JavaScript テストコード]で検索すると、テストフレームワークの使い方がでてきて 「いままでテスト書くの嫌だったけど、この際、まなんでみた。」 「簡単で良かった。」 みたいな、xUnitの使い方。みたいなことが書かれていて、少し"ん？"と感じます。 なぜかというと、テストってのは、テストフレームワークを使わなきゃできませーん。という勘違いしている人が非常に多いように感じるからです。テストを書いている人の、10人中8人は、その勘違いしています。(体感) aUnitでも、bUnitでも、cUnitでも、dUnitでも、eUnitでも、fUnitでも、 JUnitでも、NUnitでも、xUnitでも、QUnitでも、ともかくなんのテストフレームワークでもいいですけど、そんなものはどれでもいいんです。 どれもやっていることの本質は
DI (依存性注入) って何のためにするのかわからない人向けに頑張って説明してみる - Qiita
追記 2022/11/12 追記 この記事読んで、DI 便利だなって思ったらこちらも併せて読んでみてください。クリーンアーキテクチャーの開設の中で依存性逆転の説明が出てきます。難しいかもしれませんが、一度理解すればつぶしが効く考え方なので腰を据えて読んでみてください。 本文 ここでは、最近のそこそこの規模のアプリだと大体使われてる（と私は思ってる）Dependency Injection（DI）について、何故使ってるのか？というのを私の理解で書いていきたいと思います。 今回の対象言語は C# ですが、DI 使ってる言語であれば大体同じ事情なのかなと思います。 単体テストしたいよね アプリケーションを作るとうまく動いているかテストをすると思います。 たとえ、そのアプリがハローワールドだとしても動かして目視で確認してると思います。 もうちょっとアプリの規模が大きくなってくるとクラス単位やクラス
アメリカTech企業コーディングテストの傾向と実例（Front End Developer 用） - hoshki.dev
履歴書とポートフォリオの審査を通過したらテクニカルインタビューに進みます。コーディングテストとはテクニカルインタビューの一環で、実際にコードを書いて簡単なプロダクトを作るテストです。Front End Developer の場合テストはほぼ100% JavaScript 重視です。 前述の仕事探し期間に10社以上のコーディングテストを受けました。コーディングテストをそれだけ受けるというのはそれだけ不採用になっている、ということでもあるので僕のレベルが知れてしまいますが、例え不採用でもコーディングテストは 実際に雇ってもらえるレベルを知れる それに対して自分の位置がわかる テストを通して新しい技術を習える 企業の開発スタイルを習える これらを一気に得られる絶好の機会だと思います。 コーディングテストの後にはレビューとフィードバックがあり、その際に良かった点や悪かった点を聞くと丁寧に教えてくれ
Commentary of the LINE's Coding Test
2020.03.07 Kazuhiro Osawa / LINE Service Development Department1 LINE Engineer Meetup for Students ～コーディングテスト対策ウェブセミナー～ https://acaric.jp/special/event/20200307-line-engineer-meetup-for-students-in-kyoto?utm_source=Twitter&utm_medium=social&utm_campaign=20200307-line-engineer-meetup-for-students-in-kyoto
コーディングテストに打ち勝つ - Qiita
ITエンジニアが転職活動をする中で、コーディングテストに出会うことがあると思います。 私もちょうどコーディングテストに出会い色々と対策を行いました。 これからコーディング試験に臨む人の力になればと思い、簡単にまとめておきます。 エンジニアとしての最低限持っていてほしい実装力、アルゴリズムの構築力が問われる試験だと思います。 私の知る限り、下記の３種類があります。 - オンラインサイトでの試験 - 電話で画面を共有しながら問題を解いていく試験 - オンサイトでホワイトボードに問題を解いていく試験（Googleなどで実施されるやつ） 筆者は一番上に３回ほど出会いました。今回は、このオンライン試験形式についてまとめようと思います。 オンライン試験 出題範囲 間違いなくアルゴリズムの問題は出ます。範囲は幅広く、基本的な動的計画法などはおさえておく必要があります。 後は職種や技術領域に応じて、知識問
A/Bテストよりすごい？バンディットアルゴリズムとは一体何者か - Qiita
オバマ大統領の再選に大きく寄与したことで大きな注目を集めているA/Bテスト。A/Bテストを導入した、することを検討している、という開発現場も多いのではないだろうか。 そんな中、Web上で次のような議論を見つけた。 20 lines of code that will beat A/B testing every time Why multi-armed bandit algorithm is not “better” than A/B testing 一言でまとめると「A/Bテストよりバンディットアルゴリズムの方がすごいよ」「いやいやA/Bテストの方がすごいし」ということだ。 で、バンディットアルゴリズムとは一体何者なのか？ そこでBandit Algorithms for Website Optimization (O'REILLY)を読んでみた。その結果分かったことを踏まえてざっくりと
ドスパラSSD騒動、リマーク疑惑が言いがかりであること
先日、ドスパラがリマーク疑惑をかけられた自社ブランドのSSD「Z1シリーズ」の調査結果を発表し、そこそこ反響を呼んでいるようです。「疑惑はそこじゃない」というのが主流の反応なのですが、ここで反論しておこうと思います。 私の中での結論は、「誰も何も問題のある行動をしていないし、製品にも問題はない」です。順を追って説明します。 念のため書いておきますが、私はドスパラの関係者ではありません。 ・疑惑とは何だったのかそもそもの疑惑は、某ツイッターアカウント（アカウントAとします）が「Z1」を購入して分解し、疑惑を突きつけたところから始まります。「Z1」発売に当たり、ドスパラの公式ツイッターアカウントが分解写真を載せ、MicronのNANDが乗っていますね、というようなツイートをしたのですが、それにアカウントAが反応した形です。 分解したところ、NANDチップの表面がコーティングされていることに気付
TDDという名の幻想... - Qiita
TDDは死んだ。テスティングよ栄えよ。 by DHH http://d.hatena.ne.jp/yach/20140424#p1 【翻訳】TDD is Fun http://diskogs.hatenablog.com/entry/2014/04/25/085112 を読んで思ったことをつらつらと書いてみます。 TDDはできれば、やったほうが良いのは確か？です。 しかし、実際の開発現場で全面的に採用するのは ミドルウェア等の画面の存在しないソフトの開発以外では ほとんどの場合、無益です。 なぜなら、TDDを採用すると開発時間が膨らむ、すなわち、開発コストが 膨らむからです。そして、ソフト開発では細かな仕様は変化していきます、 するとTDDではそれに合わせ、テストを修正していかなくてはなりません。 また、TDDで書かれたテストが全てのケースを抜けなく網羅できていること は稀です、抜けは必ず
悪用厳禁：絶対に成功するA/Bテストの作り方
ソフトウェアエンジニアの間でも一般的な言葉になった「機械学習」。本書では、その機械学習やデータ分析の道具をどのようにビジネスに生かしていけば良いのか、また不確実性の高い機械学習プロジェクトの進め方などを「仕事で使う」という観点から整理し… オライリージャパンさんからは、売れ行きがとてもいいという話を伺っており、これで新しいノートPCを買う足しになるかなぁと思っています。 物理本については少数ですが、Cloudera World Tokyo2017で限定販売されるそうです。CWT2017申し込みが始まったので、物理版がほしい方は申し込むとよいんじゃないでしょうか。 書評もいくつか届いており、勝手ながら紹介させていただきます。
テスト(コード)レビューの方針 書きなぐり版 - うさぎ組
牛尾さんのブログをはてブったら、「じゃぁ、その手本を見せろやゴルァ」と言われたので書きました。雑です。すみません。 元記事 「自動化対象のユニットテスト（単体テスト）の仕様書を書くことは完全なる無駄である」 Blogs - Live DevOps in Japan! - Site Home - TechNet Blogs 僕のコメント 「だいたい同じ意見だけど、これで単体テスト仕様書がいらない理由にはならないかなぁと思った。テストレビューの成長方法について書かれていないしなぁ。出来る人いない現場は諦めろってことかな？」 はてなブックマーク - kyon_mm のブックマーク - 2016年1月25日 牛尾さんのコメント「どっかに書いてありますか？もしあったら記事にはります。」 僕のコメント「書いていません！」 僕のコメント「書きました！」 僕の主張 本記事は僕の実験結果（経過報告）であり、
状態遷移図／表、すなわち設計をコードでテストする
状態遷移表からひな型コードを生成する この状態遷移表からコードを起こすわけですが、状態遷移の実装については『StateパターンでCSVを読む』を書きました。デザイン・パターンの一つ:Stateによる実装です。今回の実装はC、継承も仮想関数も使えないという利き腕を封じられた条件なので戦術を大きく変えにゃならんです。 状態遷移の実装は要するに「（1）現状態 と （2）受理したイベント の組」に対応する「（3）アクション と （4）遷移先（新たな状態）」を引き当てることに他なりません。ならば上記（1）～（4）の並びをレコードとし、そのレコード列（＝状態遷移表）から「（1）現状態 と （2）受理したイベント の組」に一致するレコードを探し出して「（3）アクション を実行して （4）新たな状態 に遷移」すればいい。 状態遷移表からひな型コードの生成には使い慣れた「T4-template」を用います。
成功者が持つ｢グリット｣才能でも努力でもない第3の要素とは - ログミー[o_O]
成功者が共通して持つ「グリット」という能力--才能でも、努力でもない第3の要素とは？ 成功のカギは、やり抜く力 #1/2 成功に必要なのは努力か、才能か？ 長年にわたり議論されるこの問いに対して、心理学者のAngela Lee Duckworth（アンジェラ・リー・ダックワース）氏は、新たな説を提唱します。彼女が語った、第３の成功因子「グリット」とは？（TEDより） 教師がすべきは生徒のモチベーションを高めること アンジェラ・リー・ダックワース氏（以下アンジェラ）：27歳のとき、私は高度な技能が要求される経営コンサルティングの仕事を辞め、更に高度な技能が要求される仕事に転職しました……教師になりました。 ニューヨーク市内の公立学校で、7th grade（日本でいう中学1年生）の子供たちに数学を教えていました。多くの先生方がやっているように、質問や問題を出して解かせたり、テストをしたり、宿題
![成功者が持つ｢グリット｣才能でも努力でもない第3の要素とは - ログミー[o_O]](https://cdn-ak-scissors.b.st-hatena.com/image/square/ba1094eea15c2f8329ca3053e21d7a53f48dbfa0/height=288;version=1;width=512/https%3A%2F%2Fimg.logmi.jp%2Fwp-content%2Fuploads%2F2014%2F12%2Fc770d9f9ea6dfb9746429605e2b126e8.jpg)
「ほとんどのユニットテストが役に立たない理由」を読んで | POSTD
数ヶ月前、私はJames O Coplienの ほとんどのユニットテストが役に立たない理由 という記事に出会いました。Jamesはほとんどのユニットテストは無意味であると考えていて、タイトルは内容をそのまま正確に表しています。彼は 追加記事 で議論をさらに展開しています。私は彼の議論に大変興味をそそられました。というのは、私はユニットテストから多くの利益を得ているからです。私たちはどうしてこのような異なる見解を持つに至ったのでしょうか？ 私が何かを見逃したのでしょうか？ 結局のところ私は彼の見解に賛成できませんでした。以下は彼の記事に対する私の意見です。 ユニットテストが必要な場合 私の経験では、ユニットテストはアルゴリズムロジックに対して行う時に最も有益です。結合度の高いコードについてはその性質から特に有益ではありません。結合度が高いコードはユニットテストのために多くのモックオブジェクト
【ノンプログラマ向け】プログラマの仕事内容を理解する(1) ～「テスト」という工程が必要な理由 | きのこる庭
前書き 「一緒に働いている以上、プログラマのことを理解して仕事をしたい」そう考えている企画・ディレクションの方は経験則的に少なくない。 ノンプログラマから見て、プログラマの仕事はイメージが湧きづらく、何故その工程にそこまでのコストをかける必要があるのかわからない事が多い。 プログラマは作業の必要性を説明してくれるかもしれないけれど、専門用語も多いしイマイチピンとこなかったりする。 ここで重要なのはまさに「イメージ」だと思う。すなわちイメージを提供するための良質なメタファーだと思う。メタファーが良質であれば より直感的に理解できる。 実際メタファーの力はバカにならない。「Chef」も「Jenkins」も それぞれ 統一的な世界観が学習者の直感的な理解を後押ししてくれる。 というわけで、今回から数回に分けて なるべく「技術的な話」をせずに イメージを想起しやすいストーリーを導入することで プロ
転職会議が40日で登録数2.23倍を達成する為に行った32回のA/Bテスト【前編:効果的なKPIとテスト設計】 | KAIZEN platform blog
「来月末までに登録数を2倍に！」 一見無理そうなこの目標に挑んだのは株式会社リブセンスの転職会議運営チーム。 “40日間”という限られた期間の中で多額のプロモーション費をかけるわけではなく、A/Bテストを中心としたサイトの改善を徹底的に回し続け、短期間で登録数を向上させることに成功しました。 今回はディレクターとしてこのプロジェクトを牽引されていた黒澤氏に伺った、数多くのA/Bテストを実施し、成果を出すために大切なKPIやテスト設計の考え方を紹介します。 （写真の右から4番目がお話を伺った黒澤氏） ■なお今回の事例記事は全3回にわけて紹介します 【前編】効果的なKPIとテスト設計のコツ（本稿） 【中編】実践A/Bテストケーススタディ（後日公開予定） 【後編】チーム・文化作りのポイント（後日公開予定） 圧倒的なスピードでテストを回すためのKPI・テスト設計 『来月末までに残された日数は4
iPhone／Android含むブラウザ自動テストの最終兵器Selenium WebDriverとは
Webアプリケーションのテスト自動化をサポートするツール「Selenium WebDriver」は2011年にリリースされました。 Selenium WebDriverは広範なWebブラウザのサポートを行っていた「Selenium1（Selenium RC）」と高速軽量で汎用的なWebブラウザエミュレータの機能を持つ「WebDriver」を統合したものです。 本稿では、Selenium WebDriverを簡単に試してみたい方や自動テストの実施を検討している方のために、前後編に分けて紹介します。Selenium WebDriverの特徴を整理するとともに、Selenium WebDriverを利用したWebアプリケーションに対する簡単な自動テストの実装、実施手法について解説します。 本稿で使用する用語の説明 Selenium WebDriver Selenium WebDriverはSel
Selenium VBAを使って自動でブラウザーを操作してスクショをExcelに張り付けてみた
クライアントからシステム開発案件を受注し、開発成果物を納品する際に、エビデンスとして、Excel上に貼り付けたスクリーンショット（以下、スクショ）を、成果物の仕様書や納品書と共に納品する場合がある。この作業は、クライアントに「こういったテストを実行しました」という証拠を提示するものとなる。クライアントに成果物の機能や制限事項などを説明する場合に大変に有効なものとなっているのが現状だ。 実際、Excel上に記述したテスト仕様書や納品書にスクショを張り付けて、成果物の一部として納品しておくと、後々何らかのトラブルが発生した場合も問題解決に大きく寄与することになる。 しかし現実問題として、成果物の機能のスクショを、Excel上に手作業で延々と張り付けていく作業は単純作業であることもあり、開発者にとっては苦痛この上ない作業だ。 そこで、そのような作業を自動化し手助けをしてくれるツールとして「Sel
WebのUIテスト自動化 - Seleniumを使ってみる - Qiita
Appiumを色々触っているんですが、仕組みが同じSeleniumもちょっと触ってみました。 だいぶ色々なことができそうなのでこちらも触りつつメモを取っていこうと思います。 実際の動画デモ 実際にどんなことができるのか、参考動画を撮ってみました。 内容的にはネタな感じにしていますが、どんなことができるか分かってもらえるかと思いますｗ Seleniumとは Seleniumはクロスブラウザ、クロスプラットフォームのUIテストツールです。 ブラウザに表示される要素を操作し、取得して想定されうる状態になっているかをテストできます。 また、画面のキャプチャを撮ることもできます。 検索してみると有用な記事がいくつかあるので、詳細はそちらを見てください。 ここでは簡単に触ったメモや所感を書いていきます。 JavaScriptテスト自動化ツールSeleniumのこれまでとこれから（前編）。第1回 日本S
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
テスト駆動開発とマイクロサービスのせいで短命に終わったスマホゲームの話
