並び順

ブックマーク数

期間指定

  • から
  • まで

41 - 80 件 / 95件

新着順 人気順

UnitTestの検索結果41 - 80 件 / 95件

  • SCOUTER開発者ブログ

    2024-04-29 CSSってどんな勉強をしたらいいの?おすすめの勉強法3選! 文字やタブなどWebサイトのデザインを作成するマークアップ言語がCSSです。 CSSを勉強すると、おしゃれなWebサイトやかっこいいWebサイトが作れるようになります。 また、Webサイトを作るときに必要なHTMLを理解するのにも役立ちます。 CSSを勉強するならできるだけ効率よく勉強できるようになりたいですよね。 ではCSSの勉強法はどのようなものがあるのでしょうか。 CSSの勉強法は、スクール […] 2024-04-29 WEBエンジニアから見たXserverの使い勝手と評判 レンタルサーバーのおすすめサイトを見ると、大体どこでも上がってくる有料のレンタルサーバーの一つに「Xserver」があります。 このXserverとは、どのようなサーバーで、サービスにはどのようなものがあるのか。 ホームページ関連

      SCOUTER開発者ブログ
    • はてなやクックパッドの開発現場で、CIやテストはどう行われているのか?(前編)。CROSS 2014 - Publickey

      Web技術について横断的に語り合うイベント「CROSS 2014」が1月17日、都内で行われました。 そのセッションの1つ「現場に聞く!テスト/CI/DevOps、実際のところどうなの」では、フリーランスエンジニアの伊藤直也氏がセッションオーナーとして司会を担当し、クックパッドで開発まわりのエンジニアをしている舘野祐一氏、はてなでアプリケーションエンジニアをしている伏井洋平氏、KAIZEN platform Inc.の石橋利真氏らがスピーカーとして登壇。 先進的な現場でテストやCIがどのように行われ、エンジニアのチームがどのように情報共有をしているか、本音で語るという注目すべき内容でした。本記事ではそのダイジェストを紹介しましょう。 現場に聞く!テスト/CI/DevOps、実際のところどうなの 伊藤 今日のテーマとしてはCI(Continuous Integration、継続的インテグレー

        はてなやクックパッドの開発現場で、CIやテストはどう行われているのか?(前編)。CROSS 2014 - Publickey
      • TDDは死んだ。テスティングよ栄えよ。 by DHH | 2014-04-24 - やっとむでぽん

        DHHの"TDD is dead. Long live testing."を、訳してみました。 翻訳 やっとむ By David Heinemeier Hansson on April 23, 2014 著 David Heinemeier Hansson 2014年4月23日 Test-first fundamentalism is like abstinence-only sex ed: An unrealistic, ineffective morality campaign for self-loathing and shaming. テストファースト原理主義は禁欲のみを唱えた性教育のようなものだ。つまり、自己嫌悪に陥っている人に向けた、非現実的で効果のない、道徳教育のようなものだ。 It didn't start out like that. When I first disco

          TDDは死んだ。テスティングよ栄えよ。 by DHH | 2014-04-24 - やっとむでぽん
        • 職業プログラマーなら必ず読むべき「Code Complete」 - $shibayu36->blog;

          Code Completeの上下巻を読んだ。 CODE COMPLETE 第2版 上 完全なプログラミングを目指して 作者:スティーブ マコネル日経BPAmazonCODE COMPLETE 第2版 下 完全なプログラミングを目指して 作者:スティーブ マコネル日経BPAmazon 読んだ感想としては、職業プログラマーなら必ず読むべき本だなと感じた。 この本ではソフトウェアコンストラクションに関する話題を扱っている。この本の中でソフトウェアコンストラクションとは、詳細設計、コーディングやデバッグ、単体テストなどなど、要求定義が終わった後、ソフトウェア製作に必要なプロセス全般のことを指している。 主なテーマとして、どうやってソフトウェアにおける複雑さを減らすことが出来るのか、について書かれている。そのテーマをいろいろな観点から説明されている。例えば以下の様な観点がある。 上流工程の欠陥による

            職業プログラマーなら必ず読むべき「Code Complete」 - $shibayu36->blog;
          • Private Presentation

            Private content!This content has been marked as private by the uploader.

              Private Presentation
            • フロントエンドの負債と向き合う - mizchi's blog

              某所で書いたものを公開用に書き直したもの 前提 フロントエンドでTDDは難しい、というかほぼ不可能である。なぜなら事前に副作用をデータとして表現できるか不明だからだ。たとえばあなたのプロダクトの画面の何処かにボタンを追加するために、その内部表現を事前に思い浮かべることが可能だろうか? react-redux などのFluxフレームワークは如何に副作用をアクションとして表現することで、テスト・デバッグのための情報を残すか、という視点で発展してきた側面がある。あの冗長なアクション定義は、全てデバッグのために書いていると言っても、過言ではない。それすら「Textは文字がある」といったトートロジーなデータになりがち。 フロントエンドの現実的な単体テストは、他の開発者のために、自分が書いたコードの要求を満たしているか検知する手段として、防衛的にテストアフターしておく。これぐらいしか現実的な手法がない

                フロントエンドの負債と向き合う - mizchi's blog
              • テスト駆動開発チートシート - やさしいデスマーチ

                TDD(テスト駆動開発)のチートシートを作ってみた。 TDDBCでid:t-wadaさんが話している内容とかテスト駆動開発入門から引っ張ってきています。 ダウンロードはこちらからどうぞ。 PNGイメージ: http://dl.dropbox.com/u/1393956/tdd_cheatsheet.png PDFファイル: http://dl.dropbox.com/u/1393956/tdd_cheatsheet.pdf 追記 印刷・再配布などはご自由にどうぞ。 もし、元データ(OmniGraffle)が欲しいという人は、コメント欄かTwitter経由で教えていただければ差し上げます。 追記2 このチートシートは、OmniGraffleで作りました。他に使えそうなツールとしては、イラレとか。Visioでもたぶん作れると思います。

                  テスト駆動開発チートシート - やさしいデスマーチ
                • JavaScriptフレームワーク選定の議論 - Qiita

                  相談内容 既存の管理ツールを新しく作り直すために新しいJSフレームワーク/言語使いたいのですが、何を選んだらよいでしょうか? ここで選んだものは今後新しく作る時にも使用していく予定のため、学習コストよりメンテナンスしやすいものを選びたいと考えています。 利用者は社内外で特定の権限を持った人のみであるため、サーバサイドレンダリングはしない予定です。 言語は型があるものを利用したいのですが、TypeScriptとFlowのどちらがよろしいでしょうか? 時間に余裕があれば、テストフレームワークやビルドツールについてもお聞きしたいです。 現在のページ/チーム jQueryなどで書かれている部分が多いですが、変更を加えることが難しくメンテナンスコストが高いです。 サーバサイドをやってる人が片手間で書くJavaScriptといった状況です。 今回新規で数ページを追加する必要があるため、何を利用すれば良

                    JavaScriptフレームワーク選定の議論 - Qiita
                  • Loading

                    • 負荷試験ツール「インターネット破壊」を公開しました : DSAS開発者の部屋

                      負荷試験ツール インターネット破壊を公開しました。 こちらはずっと社内で負荷試験に使用していたツールです。社内で使用していたものなので、ソーシャルアプリ向けの機能などが多少追加されていますが、もちろんんそれ以外のWebアプリケーションでも使用できます。 基本的にはApache JMeterのようなWebアプリケーションむけのシナリオ負荷試験ツールです。コマンドラインオペレーションだけで実行でき、サーバー上で簡単に負荷試験を実施できるのが特徴です。POSTリクエストなどはもちろん、レスポンスのチェックやUserAgentの偽装、ランダムな値をパラメーターにセットする機能も実装しています。 注意: 当然ながら自分の管理下にないサイトに向けて負荷試験ツールを実行するのは絶対にやめてください。非常に危険です。 物騒な名前がついていますが、これは完全にわたしの小児的感性の趣味によるところです。地震で

                        負荷試験ツール「インターネット破壊」を公開しました : DSAS開発者の部屋
                      • 結合テストと呼ぶのをやめた話 - asterisc

                        はじめに 最近、意図的に「単体テスト」「結合テスト」という呼び方を避け、Google Testing Blogで紹介されてるTest Sizesによる分類(small / medium / large)に従った呼び方でテストを呼んでいる。 この分類方が自分の身の回りに徐々に浸透してきて、実際のチーム内のテスト戦略も一歩進んだ議論ができるようになってきたので、改めてまとめる。 ちなみにこの記事の話は手動で行われるテストではなく、自動テストを対象としているが本質はあまり変わらないと思う。 続き書きました。 akito0107.hatenablog.com 「単体テスト」「結合テスト」という呼び方について ソフトウェア開発に従事していれば必ず聞く言葉だと思う。改めて他のサイトから引用する形で定義をまとめておく。 単体テストとは *1 単体テストとは、プログラムを検証する作業の中でも、プログラムを

                          結合テストと呼ぶのをやめた話 - asterisc
                        • フロントエンドに秩序を取り戻す方法 〜はてなブログ編集画面をリニューアルするためにやったこと〜 // Speaker Deck

                          東京Node学園祭2015

                            フロントエンドに秩序を取り戻す方法 〜はてなブログ編集画面をリニューアルするためにやったこと〜 // Speaker Deck
                          • Rubyist Magazine - スはスペックのス 【第 1 回】 RSpec の概要と、RSpec on Rails (モデル編)

                            『るびま』は、Ruby に関する技術記事はもちろんのこと、Rubyist へのインタビューやエッセイ、その他をお届けするウェブ雑誌です。 Rubyist Magazine について 『Rubyist Magazine』、略して『るびま』は、日本 Ruby の会の有志による Rubyist の Rubyist による、Rubyist とそうでない人のためのウェブ雑誌です。 最新号 Rubyist Magazine 0058 号 バックナンバー Rubyist Magazine 0058 号 RubyKaigi 2018 直前特集号 Rubyist Magazine 0057 号 RubyKaigi 2017 直前特集号 Rubyist Magazine 0056 号 Rubyist Magazine 0055 号 Rubyist Magazine 0054 号 東京 Ruby 会議 11 直

                            • ウノウラボ Unoh Labs: WEBアプリテストのチェック項目リスト

                              こんにちは!やまもと@テスト番長です。 TestingGeekという耳障りの良い名前のサイトをご存知でしょうか? 総合的にテストの話を取り扱っており、それでいて読みやすいサイトです。 そこのTemplatesのコーナーにWeb Application Testing Checklist という便利そうなものがありましたので、日本語にしてみました。 ちょっとそのままだと物足りない感がありますが、テストポリシー作成の叩き台に使ってみるのも良さそうですね。 この手のリストを他にもご存知の方がいらっしゃれば、是非ご一報ください。 1. 機能テスト 1.1 リンク 1.1.1 記載された通りの先に遷移するか 1.1.2 どこからもリンクされないページは存在しないか 1.1.3 全ての外部リンク 1.1.4 参照しているサイトおよびメールアドレスはハイパーリンクになっているか? 1.1

                              • MMORPGで考えるレベルデザイン

                                ゲームの仕様書を初めて作成する人のための足掛かりのスライド ゲームの仕様書を書こう1 仕様書作成の分業とリストの作成 https://www.slideshare.net/ChizuruSugimoto/ss-173331109 ゲームの仕様書を書こう2 仕様書に記載する機能内容 https://www.slideshare.net/ChizuruSugimoto/ss-173332578 ゲームの仕様書を書こう3 仕様書に記載するデータと画面 https://www.slideshare.net/ChizuruSugimoto/ss-173333150 ゲームの仕様書を書こう4 仕様書作成で楽をするconfluenceの活用 https://www.slideshare.net/ChizuruSugimoto/confluence-173333413

                                  MMORPGで考えるレベルデザイン
                                • RSpec の入門とその一歩先へ - t-wada の日記(旧)

                                  和田 卓人(@t_wada) 作『RSpec の入門とその一歩先へ』はクリエイティブ・コモンズ 表示 - 継承 4.0 国際 ライセンスで提供されています。 東京 Ruby 会議 03 の RSpec ワークショップの資料です。このワークショップでは参加者の方に「写経」(コードを書き写すこと)をして貰い、TDD/BDD と RSpec を同時に学べるように都度説明を入れるかたちで行いました。 第2イテレーションも書きました。続きに興味ある方はご覧下さい (更新) 第3イテレーションも書きました。続きに興味ある方はご覧下さい 1st iteration favotter の みたいな NG ワードのフィルタリング機能を RSpec で作りましょう。まずは NG ワードの検出機能を作成します。 このイテレーションでは最初ベタな形のテストコードと実装を書き、だんだんとそのコードを洗練させてゆきま

                                  • 2017年JavaScriptのテスト概論 | POSTD

                                    本稿は、JavaScriptのテストについて最も重要な根拠、用語、ツール、アプローチなどの知識を身に着けることを目的とした簡略版ガイドブックです。本稿で検討する数々の側面に関する最新の秀逸な記事も紹介しつつ、私たちが経験的に得たことも多少付け加えたいと思います。 Facebookによるテスト用フレームワークであるJestのロゴをご覧ください。 見てお分かりのように、このフレームワークは「苦痛のない」JavaScriptのテストをスローガンに掲げています。しかし、 “次のように言う人” もいます。 苦痛のないテストなんてあり得ない。 実際、Facebookはこのスローガンを掲げるだけの素晴らしい理由があります。一般的にJSのデベロッパは Webサイトのテストにあまり満足していません 。JSのテストには制限があり、実装が難しく、低速である傾向があります。 一方、正しい戦略を立てて適切にツールを

                                      2017年JavaScriptのテスト概論 | POSTD
                                    • 16年間うごいているWebアプリケーションが抱えていた技術的負い目を考察する | GMOメディア エンジニアブログ

                                      技術推進室の浅井です。 技術的負い目とは、世に言う技術的負債のことです。 社内で技術的負債の定義、ことばの表現を考える中で、「『負債』は優れた比喩表現であるものの、第三者への返済義務がない点で会計上の負債とは異なり、言葉としての問題も多く、不必要な議論を生み出しやすい」などの指摘があり、代わりの表現として社内の一部で使われている言い回しです。 最近社内のたいへん古いシステム(16年の歴史があります)の技術推進を行う機会があり、たくさんの技術的負い目と向き合いました。 そのような古いシステムの技術的負い目と向き合ったとき、エンジニアはストレスを感じ、ネガティブな感情を抱いてしまいがちです。負い目に苦しめられることで過去のコードや技術的判断に対して不満を言いたくなる気持ちはとてもよくわかりますし、実際に私もたくさん苦しんでたくさん不満を言いました。 ですが技術的負債の文脈でよく言われるとおり、

                                        16年間うごいているWebアプリケーションが抱えていた技術的負い目を考察する | GMOメディア エンジニアブログ
                                      • 組織にテストを書く文化を根付かせる戦略と戦術

                                        組織にテストを書く文化を根付かせる戦略と戦術 Feb 16, 2016 @ 日本OSS推進フォーラム Read less

                                          組織にテストを書く文化を根付かせる戦略と戦術
                                        • Android開発をする上で知っておいてほしいなと思うこと - こやまカニ大好き

                                          現在の Android Developers の情報は非常に充実していて、Developer Guides を順に読み進んでいくだけで開発に必要な知識とGoogleが想定している(であろう)最も基本的な実装を学ぶことができる。 特にこの「基本的な実装」というものが重要で、これを知っておかないと開発者間の意思疎通がスムーズに行えなかったり、そもそも気をつけておくべき注意点を見落としがちになってしまう。 とはいえ、今の膨大な公式ドキュメントをただ読めというのは厳しいので、Android開発をする上で最低限理解しておいてほしい(と僕が思っている)事柄と、それについて知ることができるドキュメント類についてまとめてみることにする。 2018/03/25 : リリース周りについて別記事に追記した。 nein37.hatenablog.com 公式ドキュメントの重要ページ 公式ドキュメントと言った場合、

                                            Android開発をする上で知っておいてほしいなと思うこと - こやまカニ大好き
                                          • 品質保証部門の陳腐化。そして陳腐化した品質保証は品質を悪化させる - 千里霧中

                                            ※品質保証のエンジニアである筆者が自省・戒めのために書いた記事になります 品質管理(Quality Control)、品質マネジメントは国内では製造業を中心に発展し、プロダクトの競争力向上に貢献してきました。 JTCと呼ばれる旧来からのメーカーでは、その実績・年功の蓄積に応じて、独立性を保った品質管理・品質保証部門が権威を獲得し、今でもソフトウェア開発に強い影響力を保持するようになっています。筆者は複数のメーカーを転職やコンサルで巡って来ましたが、例えば品質保証部門が承認しないとマイルストーンで開発がブロックされる、プロダクトがリリースできないといった権限を持つ体制が、今なお普遍的に見受けられます。 この品質保証部門が権力を持ち、品質ゲートの門番として振る舞う体制は、今であっても、ある面で恩恵を提供しています。例えば次のようなものです: 法規制対応、標準化対応、その他公的なガバナンス要求へ

                                              品質保証部門の陳腐化。そして陳腐化した品質保証は品質を悪化させる - 千里霧中
                                            • 世界のJavaScriptを読もう @ 2012

                                              調べる方法を知る JavaScriptは調べるとやり方が見つかることが多い 古いものと最近のものがまざってる ごく最近〜未来のものは見つけにくい 以下の総集編的な内容 海外のJavaScript情報を見つけよう 世界のJavaScript情報を読もう 今からRSS購読すべきタグと検索結果 ブラウザの最新情報を知るために、Web開発者が読んでおくべきブログ Webの動きはとても早いので、調べ方を知る

                                              • 【翻訳】テスト駆動開発の定義 - t-wadaのブログ

                                                このブログエントリでは、テスト駆動開発(TDD: Test-Driven Development)の考案者Kent BeckがTDDの定義を改めて明確化した文章を、許可を得たうえで翻訳し、訳者の考察を沿えています。 きっかけ 2023年の年末、テスト駆動開発(TDD: Test-Driven Development)の考案者Kent Beckは、substackにTDDに関するポストを連投して論戦を繰り広げていました。TDDはその誕生から20年以上が経ち、その間に「意味の希薄化」が発生して議論が噛み合わなくなっていました。意味の希薄化(Semantic Diffusion)とは、新しく作り出された用語が広まる際に本来の意味や定義が弱まって伝わる現象です。 私(和田)はTDDと関わりの深いキャリアを歩んできました。Kent Beckの著書『テスト駆動開発』の翻訳者であることもあり、TDDの正

                                                  【翻訳】テスト駆動開発の定義 - t-wadaのブログ
                                                • Visual Studio Code and Docker - Visual Studio Code - Site Home - MSDN Blogs

                                                  In Visual Studio 2022 17.10 Preview 2, we’ve introduced some UX updates and usability improvements to the Connection Manager. With these updates we provide a more seamless experience when connecting to remote systems and/or debugging failed connections. Please install the latest Preview to try it out. Read on to learn what the Connection ...

                                                    Visual Studio Code and Docker - Visual Studio Code - Site Home - MSDN Blogs
                                                  • 6年間におけるGoのベストプラクティス | POSTD

                                                    (本稿は、QCon London 2016で行った講演の内容に基づいています。スライドとビデオは近日中に掲載予定です) 2014年に開催された最初のGopherConで、私は「 Best Practices in Production Environments(本番環境でのベストプラクティス) 」と題した講演を行いました。 SoundCloud の私たちはGoのアーリーアダプターで、その時点までに既に2年近く、本番環境向けの様々なGoコードを書き、実行し、メンテナンスしていました。そして私たちはいくつかのことを学んだので、その教訓をまとめ、多くの人に伝えたいと思ったのです。 それ以来、私はフルタイムでGoを使う仕事を続けています。SoundCloudではその後の活動やインフラチームで、そして現在は Weaveworks で Weave Scope や Weave Mesh の開発に使ってい

                                                      6年間におけるGoのベストプラクティス | POSTD
                                                    • 「現在時刻」を外部入力とする設計と、その実装のこと - クックパッド開発者ブログ

                                                      こんにちは。技術部 開発基盤グループの諸橋です。 クックパッドでは昨今の多くのWeb企業と同じように、GitHub EnterpriseのPull Requestを使ったコードレビューを広範に実施しています。わたしたちのコードレビューでは、ソースコードの字面にとどまらず、サービスの機能として魅力的かどうかや、保守性を含めた設計が適切かといった議論に発展することも良くあります。 きょうはそんななかで話題に上がった「現在時刻」の扱いかたに関する設計の話を書きます。 背景 サービスを開発・運営している我々には、時間帯によって出し分けたり、特定の期間のみに表示したいコンテンツがたくさんあります。 そのたびにデプロイし直すというのはつらいので(特に24:00に出なくなるコンテンツなど)なんとかしたくなりますが、一方で時限式のコンテンツはその時になるまでちゃんと動いているか確証が取れないので怖いです。

                                                        「現在時刻」を外部入力とする設計と、その実装のこと - クックパッド開発者ブログ
                                                      • Rを使えるようになるための10のこと - Issei’s Analysis ~おとうさんの解析日記~

                                                        Rは統計解析を行うことができる強力なツールです。計算上の信頼性はとても高く、世界中の分析者が日々分析用パッケージを公開しております。近年では行政機関で使われているという事例もちらほら聞きます。 ・姫路市役所での事例 これまでSASは使ってきたけどRは全く使ったことがない!JAVAとかC++とかガリガリ書けるけどRはよく分からない!という方々がすんなりRの世界に入れるよう、資料の探し場所や導入部分をまとめておきます。 ※まだ不完全ですが情報を入手し次第アップデートしていきます。 1. 資料を探す場所 CRAN R本体、パッケージ、PDF資料などの置き場 Task Viewに分野ごとのまとめ Searchでパッケージや資料の検索 CRANの読み方は「しーらん」派と「くらん」派でわかれる(どっちでもいいw) Rjpwiki 日本語で書かれている、これまでのRに関する資料の集大成 データの加工技、

                                                          Rを使えるようになるための10のこと - Issei’s Analysis ~おとうさんの解析日記~
                                                        • はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知

                                                          はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28

                                                            はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
                                                          • symfony - open-source PHP5 web framework

                                                            Services Platform.sh for Symfony Best platform to deploy Symfony apps SymfonyInsight Automatic quality checks for your apps Symfony Certification Prove your knowledge and boost your career SensioLabs Professional services to help you with Symfony Blackfire Profile and monitor performance of your apps

                                                              symfony - open-source PHP5 web framework
                                                            • コードの品質を維持したまま開発スピードを上げる | POSTD

                                                              高品質のコードベースは、反復作業やコラボレーション、メンテナンスを簡単にすることで、長期的な開発のスピードを上げてくれます。Quoraではベースコードの品質は重要だと考えます。 高品質のコードを維持することは利点がありますが、その反面かなりのオーバーヘッドが発生し、実際の開発のサイクルに時間が掛かってしまいます。このオーバーヘッドと利点の折り合いを付けるのは難しい問題です。この場合、2つの選択肢しかないように思えます。低品質でコードスピードが速いか、もしくは高品質でスピードが遅いか。スタートアップは素早い開発サイクルに最適化しているので、多くの人は低品質で進めたほうがいいと思っています。 このジレンマは解消できます。ツールやプロセスを工夫することで、コードベースの品質を維持したままスピードを速めることができるのです。この投稿では、コードの品質に関しての私たちの考えや、2つの世界を共存させる

                                                                コードの品質を維持したまま開発スピードを上げる | POSTD
                                                              • JavaScriptテストの基礎知識と使えるフレームワーク6選

                                                                JavaScriptテストの基礎知識と使えるフレームワーク6選:フレームワークで実践! JavaScriptテスト入門(1)(1/3 ページ) しっかりとJavaScriptの“テスト”を行うために、最近のJavaScript事情やテストを取り巻く環境、今注目のテストフレームワークを6つ紹介する JavaScriptでもテストを書こう @ITの読者の方たちのほとんどは、どのような言語を主に利用しているのかなどの違いはあるにせよ、日常的にプログラムを書いている方たちが多いかと思います。 アプリケーションを作る、ライブラリを作成する、オープンソースプロジェクトに貢献するなど、皆さんがプログラムを書く場面はそれぞれいくつかあるはずです。それらプログラムを書く場面に共通して大切な習慣の1つとして、「作成するプログラムに対しては必ずテストコードを書く」ことがあるのは、誰にでも同意してもらえることでし

                                                                  JavaScriptテストの基礎知識と使えるフレームワーク6選
                                                                • 自動テストに限界を感じた私がなぜ形式手法に魅了されたのか - 若くない何かの悩み

                                                                  長らく自動テストとテスト容易設計を生業としてきましたが、最近は色々な限界を感じて形式手法に取り組んでいます。 この記事では、既存の自動テストのどこに限界を感じてなぜ形式手法が必要なのかの私見を説明します。なお、私もまだ完全理解には程遠いため間違いがあるかもしれません。ご指摘やご意見はぜひ Kuniwak までいただけると嬉しいです。 著者について プログラマです。開発プロセスをよくするための自発的な自動テストを支援する仕事をしています(経歴)。ここ一年は R&D 的な位置付けで形式手法もやっています。 自動テストの限界 自動テストとは 私がここ数年悩んでいたことは、iOS や Web アプリなどのモデル層のバグを従来の自動テストで見つけられないことでした。ただ、いきなりこの話で始めると理解しづらいと思うので簡単な例から出発します。 この記事でいう自動テストとは以下のようにテスト対象を実際に

                                                                    自動テストに限界を感じた私がなぜ形式手法に魅了されたのか - 若くない何かの悩み
                                                                  • モダンなJava開発ガイド (2018年版)

                                                                    2018年現在でもJava開発をしていると、Antすら使っていないEclipseプロジェクトにそこそこの頻度で出くわします。Eclipseの自動コンパイルが通ればOKであり、ビルドはExcel手順書をもとに手動で行われ、依存関係ライブラリはもちろんlibフォルダに各種jarファイルが放り込んであります。Eclipse上以外ではどう動かせば分かる人がいないため、コマンドラインからビルドなどを行うことは叶わず、CI化なんて夢のまた夢です。 そんなJava開発から脱却したい人向けのJava開発のモダン化ガイドです。 基本的にJava 8以降での開発を想定しています。 OpenJDK/OracleJDK上での開発を想定しています。 Android開発の場合は一部適用できない可能性あり。 英語のIDE、ツール等は積極的に使用します。 英語嫌いだとモダン化は難しい。 Java開発全般を前提としているた

                                                                      モダンなJava開発ガイド (2018年版)
                                                                    • メンテナブルなJsってなんだろう

                                                                      第45回 WordBench 大阪での発表資料です。 あとがき:http://www.torounit.com/blog/2015/09/15/2088/

                                                                        メンテナブルなJsってなんだろう
                                                                      • 【ハウツー】これはすごい! Web案件必須 Selenium - 人気急上昇中自動テストツール (1) 最近人気のSelenium | エンタープライズ | マイコミジャーナル

                                                                        Webアプリケーションのテストツールに「Selenium」がある。SeleniumはJavaScriptとHTMLを使って、Webブラウザに自動でテストをさせようというもので、アジャイル開発におけるテストツールとして注目されている。 Seleniumとは SeleniumはWebアプリケーション用テストツール。JavaScript/DHTML/iframesをベースに構築されたテストツールで、Webブラウザから直接実行できるという特徴がある。要するに、目の前でWebブラウザが勝手にテスト工程を実施するわけである。見ていてなかなか気持ちがいい。対応しているプラットフォームやWebブラウザは多岐にわたる。代表的なプラットフォームは次のとおり。 Windows Internet Explorer 6.0 Mozilla Suite 1.6以上 Firefox 0.8?1.5 Seamonkey

                                                                        • テスト駆動開発(TDD)はもう終わっているのか? Part 1 | POSTD

                                                                          後編を公開しました(2014/10/8) これは、テスト駆動開発(TDD)とTDDがソフトウェア設計に与える影響についてKent Beck、David Heinemeier Hansson、および著者の3人で行った一連のディスカッションの議事録です。 ディスカッションに至った経緯 あるセンセーショナルな発言とブログ記事が発端となり、お互いの見解と経験について理解を深める目的で、話し合いが持たれました。 この会話のきっかけとなったのは、 DavidがRailsConfで行った基調演説です。 彼はRailsコミュニティでTDDおよびユニットテストへの不満を表明しました。 程なくして、彼はいくつかのブログ記事を公開しましたが、そのうちの最初の記事で “TDDは終わった” と宣言したのです。 それから2~3日後、Davidのその後の記事について私がタイプミスの修正を送ったところ、 Davidは彼の

                                                                            テスト駆動開発(TDD)はもう終わっているのか? Part 1 | POSTD
                                                                          • 瞬時にテストデータを大量生成してくれる『Data Generator』 - IDEA*IDEA ~ 百式管理人のライフハックブログ ~

                                                                            ドットインストール代表のライフハックブログ

                                                                              瞬時にテストデータを大量生成してくれる『Data Generator』 - IDEA*IDEA ~ 百式管理人のライフハックブログ ~
                                                                            • Google Chrome Developer Tools入門 in DevFestX Sapporo

                                                                              • 予防に勝る防御なし - 堅牢なコードを導く様々な設計のヒント / Growing Reliable Code PHPerKaigi 2022

                                                                                PHPerKaigi 2022 2022/04/10 10:40〜 Track A レギュラートーク(40分) PHP はバージョンを追う毎に型宣言、例外、表明、列挙型などの機能が大幅に強化され、堅牢なコードを書くための機能が充実してきました。それらの機能はどう使うと効果的なのでしょうか。 本講演では PHP 8.1 をベースにして、誤りを想定してチェックするのではなく、そもそも誤りにくい設計とはどのようなものか、つまり「予防」の観点を軸足に、堅牢なコードを導くための様々な設計のヒントをご紹介します。 Agenda - 型宣言 - 列挙型 - ドメインモデリング - 不変性と等価性 - 完全性 - レイヤーと責務

                                                                                  予防に勝る防御なし - 堅牢なコードを導く様々な設計のヒント / Growing Reliable Code PHPerKaigi 2022
                                                                                • コード内で「現時刻」を気軽に取得してはいけない | Nekoya press

                                                                                  日付を扱う処理についていろいろまとめたついでに、わりと簡単なことだけど知らないと落とし穴にハマる系のネタを。 日頃いろいろな処理を書いていて、現時刻を扱うこともは少なくないはずです。ですが、これを適当にやっていると困ることが多々あります。 実行中に「現時刻」を元にした処理が食い違う 例えばこんなコード。ログ集計とかやってるイメージです。 class Analyzer(object): def analyze(self): logfile = datetime.datetime.now().strftime('my_log_file.%H') self.save(self.analyze_logfile(logfile)) def save(self, result): now = datetime.datetime.now() self.result[now.hour] = result