SourceTreeでPUSHできない。Logon failed, use ctrl+c to cancel basic credential prompt. SourceTreeでPUSHできない。Logon failed, use ctrl+c to cancel basic credential prompt.

Kent Beck による著書「テスト駆動開発」より、TDD の概要をまとめた。 業務でTDDを行っている者として、基本に忠実にプロジェクトを進めることの難しさをよく感じるので、よい機会になった。 TDD は何を可能にするか？ TDD のゴールは、「動作する綺麗なコード」を生み出すことである。 一般的なソフトウェア開発では、「きれいな」コードを目指す前に、「動作する」事の前に多くの制約が立ちふさがる。 この問題のアプローチとして、考え込む前に、自動化されたテストによって開発を推し進める。このような開発がテスト駆動開発(Test-Driven Development: TDD)と呼ばれる。 TDD のルール TDD は、以下のシンプルな二つルールのみである。 自動化されたテストが失敗したときのみ、新しいコードを書く 重複を除去する。 これらのルールに従って開発を行うと、開発者が自分たちでテス

はじめにこんにちは！Unit～E2Eのテスト自動化を生業にしている、いしいと申します。 ユニットテストに限らず、何かを始めようと思ったとき、人は様々な壁に直面しますよね。知識・経験の問題、コストの問題（金銭、時間）、メンタルの問題（納得感、不安感）、それらが複合的に結びつく社内政治的な問題などなど・・・。そして、それらの壁を乗り越えて第一歩を踏み出すことには大変な困難を伴います。 この記事では、ユニットテストを書いていくのにあたって、どのような壁・問題があるのかを確認し、それに対してどのようにアプローチをすれば乗り越えられるのかを考えていこうと思います。 ユニットテストの壁とその乗り越え方メンタルの問題根本的にモチベーションが上がらない それはユニットテストのメリットや魅力に理解、納得がいっていないからです。人間、無駄なことをやりたいとはなかなか思えません。仮に、無駄と思いながらやったとし

渡辺です。さる方面からテスト系のエントリーがまだか…と催促されたので、ユニットテストについて少し考えてみたいと思います。 最近、TwitterのTLをチェックしていると、JUnitを利用しているにも関わらず違和感のあるTweetや、原因をJUnitにして本来解決すべき問題から目をそらしているようなTweetを多く見かけます。そこで、JUnitをによるユニットテストに関するありがちな勘違いをまとめてみました。 なお、JUnitの部分は、RSpecでもNUnitでも適当に置き換えて読んでも構いません。 1.JUnitを使うことが目的という勘違い JUnitを利用すること自体を目的にしたところで何も得る事はありません。 ありがちな話ですが、「納品物としてJUnitのテストコード（または実行結果）を求められている」ことが理由でJUnitを利用しているならば、それは足かせでしかない可能性があります。

もうちょっと規約的なものを「JavaでのUT作成基準を整理してみた」にもまとめてみました。 はじめに 去年、ブログの方に「ふつうのユニットテストのための７つのルール」という記事を書いたのですが、思ったより反響がありました。 あの記事で書いたのはあくまで原理・原則で、それを実現するためにはいくつかのテクニックが必要です。 特に、ああいうルールを作って「ユニットテストを書く事」を厳守するようにしても、 適切なテクニックを知らなければメンテが困難だったり、品質に寄与しなかったり、実行性能が悪いゴミが量産される可能性があります。 じゃあ、どうすれば良いかというと「最初からユニットテストが書きやすいように元のコードを設計する」ということです。 そう。まず身に付けるべきは「テストコードの書き方」では無く「テスト対象コード」すなわち「プロダクトコードの書き方」なのです。 また、ここで言ってる「最初から」

はじめに 「テストが大事」 これは生産性と品質を高めるための基本的な考え方です。なので 「テスト書かないと」 ってことはみんな同意するのでUnitTestらしきものが書かれてることは多いのですが、役に立たなかったりむしろ有害ですらあるテストがあふれているプロジェクトもあります。作った人に罪は無いのですが、頑張ったのに悪い方向に行ってしまうのはもったいない これはユニットテストを有効活用するための最低限のルールが守られてないためです。あまり学校で習う類のものでもないかもしれないですし、大事だと思うので個人的な見解をまとめておきました。 ポータビリティを大事にする 繰り返し実行できるように作る Unit Testですべての自動テストをしない モックやスタブを過度に使わない ひとつのテストケースにはひとつの観点しか検証しない テスト内容が分かる名前をつける ログや標準出力は極力出さない Java

はじめに Unit Testが大事、ということ自体はあまり異論はないと思うのですが、最初からTDDがしっかりできてるような現場ならいざ知らず、そうではない場合は中々うまく入れれない事も多くあります。なのでこうすると導入しやすい、という観点で以下の動画でそのあたりのことを話したのですが、補足も含めて記事でもまとめておきたいと思います。 これはユニットテストですか？ ユニットテストとは？ ユニットテストとは何でしょうか？ 一応、テストの資格試験を実施しているISTQBの定義では以下のように定義されます。 component testing (unit testing) A test level that focuses on individual hardware or software components. Synonyms: module testing, unit testing この

VS Codeの拡張機能でPythonの仮想環境構築からコード整形、Lintまでを体験してみよう：Visual Studio Codeで快適Pythonライフ（1/2 ページ） 簡単な関数を作りながら、VS CodeとPython拡張機能と各種モジュールを使って、仮想環境の構築、コード記述と整形、Lintによる問題点の発見までを見てみましょう。

環境 知見 (1) ランダムな情報を返す関数をテストする 関数 テスト 知見 (2) とある日付の前月を返す関数をテストする 関数 テスト 知見 (3) テスト結果を XML 形式で出力する メモ 以上 環境 以下のような環境でやってます. $ sw_vers ProductName: Mac OS X ProductVersion: 10.11.6 BuildVersion: 15G19009 $ python --version Python 3.6.4 知見 (1) ランダムな情報を返す関数をテストする 関数 以下のような関数を sample_1.py というファイルに作成しました. import random def select_random_key(n): k = random.choice(range(n)) return "{0:02d}".format(k) この関数は,

# -*- coding: utf-8 -*- import random class Dice(object): def throw(self): return random.randint(1, 6) # -*- coding: utf-8 -*- import collections import unittest import dice from scipy import stats class TestDice(unittest.TestCase): def setUp(self): self.__target = dice.Dice() def test_throw(self): # 6000回実行する result = [self.__target.throw() for n in range(0, 6000)] # 実行結果の集計 counted = collections