テストの「Mock(モック)」についての著名ソフトウエアエンジニアはどう思っているか🤔

職場や開発環境や対象となるサービスによっては、テストが「だるすぎ」と思えることがあります。

世界的に著名な方々の意見が気になりますよね。

どのように心得て書くべきか、というようなことをまとめてくれています。

「Mock」についてです。

👉 Unit Testing Experts on Mocks | Perry Street Software Engineering hatena-bookmark

 

👨‍💻 Martin Fowler

In classic tests, many people like the fact that client tests may catch errors that the main tests for an object may have missed, particularly probing areas where classes interact. Mockist tests lose that quality. In addition you also run the risk that expectations on mockist tests can be incorrect, resulting in unit tests that run green but mask inherent errors

When you write a mockist test, you are testing the outbound calls of the SUT to ensure it talks properly to its suppliers. A classic test only cares about the final state — not how that state was derived. Mockist tests are thus more coupled to the implementation of a method. Coupling to the implementation also interferes with refactoring, since implementation changes are much more likely to break tests than with classic testing.

I don’t see any compelling benefits for mockist TDD, and am concerned about the consequences of coupling tests to implementation. I really like the fact that while writing the test you focus on the result of the behavior, not how it’s done. A mockist is constantly thinking about how the SUT is going to be implemented in order to write the expectations. This feels really unnatural to me.

  • クライアントテストがオブジェクトのメインテストでは見逃す可能性があるエラーをキャッチできる。
  • クラス同士がやりとりする領域を調査することができる。
  • 期待値が誤っている場合、単体テストが通過し、本来のエラーが隠蔽される可能性がある。
  • メソッドの実装により結合しやすいため、クラシックテストよりもテストが破綻する可能性が高くなる。

👉 Mocks Aren't Stubs hatena-bookmark

 

👨‍💻 Robert C. Martin (Uncle Bob)

Mocking the interactions between all classes forces you to create mocks that return other mocks (that might return yet other mocks). You have to mock out all the data pathways in the interaction; and that can be a complex task. This creates two problems. 1. The setup code can get extremely complicated. 2. The mocking structure become tightly coupled to implementation details causing many tests to break when those details are modified.

The need to mock every class interaction forces an explosion of polymorphic interfaces. In statically typed languages like Java, that means the creation of lots of extra interface classes whose sole purpose is to allow mocking. This is over-abstraction and the dreaded ‘design damage’.

I recommend that you mock sparingly. Find a way to test — design a way to test — your code so that it doesn’t require a mock.

  • インタラクションをシミュレートするための便利なツール。
  • クラス同士のインタラクションをすべてモックする必要があるため、セットアップコードが複雑になる。
  • モックの構造は実装の詳細に密接に結合するため、実装の変更により多くのテストが破綻する可能性がある。
  • ポリモーフィックなインターフェースが必要となるため、設計上の過剰な抽象化が生じる可能性がある。

👉 Clean Coder Blog hatena-bookmark

 

👨‍💻 Kent Beck

I mock almost nothing. If I can’t figure out how to test efficiently with the real stuff, I find another way of creating a feedback loop for myself.

If I use TDD, I can refactor stuff. And then I heard these stories people say that they use TDD and now they can’t refactor anything. I couldn’t understand that and then I started looking at their tests: If you have mocks returning mocks, returning mocks, your test is completely coupled to the implementation, not the interface, but the exact implementation. Of course you can’t change anything without breaking the test. That for me is too high a price to pay, that’s not a trade-off I’m willing to make.

  • ほとんど使用しない。
  • 多重に入り組んでいると、テストが実装に結合しすぎるため、実装の変更が難しくなる。

👉 TW Hangouts | Is TDD dead? - YouTube hatena-bookmark

 

👨‍💻 Ian Cooper

When we refactored something all these tests with mocks broke and we had to rewrite all the mocks. It was kind of puzzling because the promise was that we should be able to refactor our code, because our tests would enable us to refactor and refactoring kept our code healthy. But the tests were an obstacle to that change, since they were breaking when we changed our implementation details.

Avoid heavy mocking. This allows you to meet the promise to refactoring. You will refactor your code and your tests won’t break.

Mocks are useful when a resource is expensive to create, but the problem with mock objects essentially is that people have used them to isolate classes. Don’t do that.

  • リソースを作成するのがコストが高い場合に便利である。
  • オブジェクトを使用すると、クラスを分離するために使用された場合、リファクタリングが非常に困難になる可能性がある。
  • ヘビーなモックは避けるべきである。

👉 🚀 TDD, Where Did It All Go Wrong (Ian Cooper) - YouTube hatena-bookmark

 

👨‍💻 まとめ

大まかにまとめると以下の3つ。

Mock はインタラクション(やり取り/相互作用)の確認が目的である。

リソース作成のコストが高い場合に便利。

実装と密になるので、実装は変更はしづらくなっていく。

ホンマもんのエンジニアの方々に口を揃えて言われるとスッキリします。


【Git】.gitignore の状態を確認するコマンドたち

git status --ignored

まずは、状態の確認をしましょう。

以下は、基本的な Android プロジェクトでの例。


 

■ 位置を確認する


❯ find . -name .gitignore                          
./app/.gitignore
./.gitignore
./.idea/.gitignore

👉 AndroidStudio 新規プロジェクトテンプレートから考える .gitignore hatena-bookmark

 

■ git status


❯ git status          
On branch main
Your branch is up to date with 'origin/main'.

nothing to commit, working tree clean

 

■ git status --ignored


❯ git status --ignored
On branch main
Your branch is up to date with 'origin/main'.

Ignored files:
  (use "git add -f <file>..." to include in what will be committed)
        .gradle/
        .idea/workspace.xml
        app/build/
        local.properties

nothing to commit, working tree clean

→ ignore 対象が確認できます。

 

■ git clean -ndX


❯ git clean -ndX
Would remove .gradle/
Would remove .idea/workspace.xml
Would remove app/build/
Would remove build/
Would remove local.properties

 

■ git check-ignore -v


❯ git check-ignore -v .gradle/           
.gitignore:2:.gradle    .gradle/

❯ git check-ignore -v .idea/workspace.xml
.idea/.gitignore:3:/workspace.xml       .idea/workspace.xml

❯ git check-ignore -v app/build/         
app/.gitignore:1:/build app/build/

❯ git check-ignore -v local.properties
.gitignore:15:local.properties  local.properties

❯ git check-ignore -v **/*
app/.gitignore:1:/build app/build
app/.gitignore:1:/build app/build/generated
app/.gitignore:1:/build app/build/generated/ap_generated_sources
app/.gitignore:1:/build app/build/generated/ap_generated_sources/debug
app/.gitignore:1:/build app/build/generated/ap_generated_sources/debug/out
app/.gitignore:1:/build app/build/generated/res
...

→ そのファイルを ignore するパターン記述を特定することができます。

 

■ git ls-files --other --ignored --exclude-standard


❯ git ls-files --other --ignored --exclude-standard
.gradle/7.5.1/checksums/checksums.lock
.gradle/7.5.1/dependencies-accessors/dependencies-accessors.lock
.gradle/7.5.1/dependencies-accessors/gc.properties
.gradle/7.5.1/executionHistory/executionHistory.bin
.gradle/7.5.1/executionHistory/executionHistory.lock
...

→ 実際に ignore されたファイル一覧が確認できます。Adroid プロジェクトでは出力行が多くなるので省略しています。

 

■ 参考

👉 Git のステータス: リポジトリの検査 | Atlassian Git Tutorial hatena-bookmark


ChatGPT で調べる Singleton Pattern

試してみます。


👉 ChatGPT hatena-bookmark

日本語ではどうなのか。

👉 Singleton パターン - Wikipedia hatena-bookmark

 

■ "java singleton"

In Java, a singleton is a design pattern that ensures that a class has only one instance and provides a global point of access to it. This is useful when you need to have only one instance of a class for the entire application, such as for managing a shared resource.

To implement a singleton in Java, you would typically create a static member in the class that holds the sole instance of the class, and provide a static method that returns the instance. This method is typically called getInstance(). Here is an example:


public class Singleton { 
    private static Singleton instance; 

    private Singleton() { 
        // Private constructor to prevent instantiation 
    } 

    public static Singleton getInstance() { 
        if (instance == null) { 
            instance = new Singleton(); 
        } 
        return instance; 
    } 

}

To use the singleton, you would call the getInstance() method, like this:


Singleton instance = Singleton.getInstance();

It is important to note that a singleton in Java is not thread-safe by default. If multiple threads can access the getInstance() method simultaneously, it is possible for two or more instances of the class to be created. To make the singleton thread-safe, you can use synchronization in the getInstance() method, like this:


public static synchronized Singleton getInstance() { 
    if (instance == null) { 
        instance = new Singleton(); 
    } 
    return instance; 
}

This ensures that only one thread can execute the getInstance() method at a time, which prevents multiple instances of the class from being created.

 

■ "javaでシングルトン"

Javaでシングルトンとは、あるクラスが1つのインスタンスだけを持ち、そのインスタンスに対するグローバルなアクセスポイントを提供するデザインパターンです。これは、アプリ全体で1つのクラスのインスタンスだけが必要な場合に役立ちます。例えば、共有リソースの管理などです。

Javaでシングルトンを実装するには、通常はクラス内にクラスの唯一のインスタンスを保持するための静的メンバーを作成し、そのインスタンスを返す静的メソッドを提供します。このメソッドは通常、getInstance()と呼ばれます。以下に例を示します。


public class Singleton {
    private static Singleton instance;

    private Singleton() {
        // Private constructor to prevent instantiation
    }

    public static Singleton getInstance() {
        if (instance == null) {
            instance = new Singleton();
        }
        return instance;
    }
}

シングルトンを使用するには、getInstance()メソッドを呼び出します。以下はその例です。


Singleton instance = Singleton.getInstance();

Javaでのシングルトンはデフォルトでスレッドセーフではありません。複数のスレッドが同時にgetInstance()メソッドにアクセスできる場合、クラスの2つ以上のインスタンスが作成される可能性があります。シングルトンをスレッドセーフにするには、getInstance()メソッド内で同期を使用します。以下に例を示します。


public static synchronized Singleton getInstance() {
    if (instance == null) {
        instance = new Singleton();
    }
    return instance;
}

これにより、1つのスレッドだけがgetInstance()メソッドを実行できるようになり、クラスの複数のインスタンスが作成されることを防ぎます。

 

■ "java で singleton"

Javaでのシングルトンとは、あるクラスが1つのインスタンスだけを持ち、そのインスタンスに対するグローバルなアクセスポイントを提供するデザインパターンです。これは、アプリ全体で1つのクラスのインスタンスだけが必要な場合に役立ちます。例えば、共有リソースの管理などです。

Javaでシングルトンを実装するには、通常はクラス内にクラスの唯一のインスタンスを保持するための静的メンバーを作成し、そのインスタンスを返す静的メソッドを提供します。このメソッドは通常、getInstance()と呼ばれます。以下に例を示します。


public class Singleton {
    private static Singleton instance;

    private Singleton() {
        // Private constructor to prevent instantiation
    }

    public static Singleton getInstance() {
        if (instance == null) {
            instance = new Singleton();
        }
        return instance;
    }
}

シングルトンを使用するには、getInstance()メソッドを呼び出します。以下はその例です。


Singleton instance = Singleton.getInstance();

Javaでのシングルトンはデフォルトでスレッドセーフではありません。複数のスレッドが同時にgetInstance()メソッドにアクセスできる場合、クラスの2つ以上のインスタンスが作成される可能性があります。シングルトンをスレッドセーフにするには、getInstance()メソッド内で同期を使用します。以下に例を示します。


public static synchronized Singleton getInstance() {
    if (instance == null) {
        instance = new Singleton();
    }
    return instance;
}

これにより、1つのスレッドだけがgetInstance()メソッド

 

■ "kotlin singleton"

In Kotlin, a singleton is a design pattern that ensures that a class has only one instance and provides a global point of access to it. This is useful when you need to have only one instance of a class for the entire application, such as for managing a shared resource.
To implement a singleton in Kotlin, you can use the object keyword. This keyword is used to create a single instance of a class. Here is an example:


object Singleton { 
    fun doSomething() {
        // Code to perform some operation 
    } 
}

To use the singleton, you can simply call its methods like any other object, without the need to call a getInstance() method:


Singleton.doSomething()

One advantage of using the object keyword to implement a singleton in Kotlin is that it is thread-safe. Because the object keyword creates a single instance of the class, and because this instance is created when the class is loaded, multiple threads cannot access the getInstance() method simultaneously, and so it is not possible for multiple instances of the class to be created. This means you do not need to use synchronization to make the singleton thread-safe.

 

■ kotlin で singleton

Kotlinでのシングルトンとは、あるクラスが1つのインスタンスだけを持ち、そのインスタンスに対するグローバルなアクセスポイントを提供するデザインパターンです。これは、アプリ全体で1つのクラスのインスタンスだけが必要な場合に役立ちます。例えば、共有リソースの管理などです。

Kotlinでシングルトンを実装するには、objectキーワードを使用します。このキーワードは、クラスの1つのインスタンスを作成するために使用されます。以下は例です。


object Singleton {
    fun doSomething() {
        // Code to perform some operation
    }
}

シングルトンを使用するには、getInstance()メソッドを呼ぶ必要がないので、他のオブジェクトのように単にそのメソッドを呼び出します。以下はその例です。


Singleton.doSomething()

Kotlinでシングルトンを実装する際に、objectキーワードを使用する利点の1つは、それがスレッド

 

■ "dagger singleton"

Dagger is a dependency injection framework for the Java and Android platform. It is not itself a singleton, but rather a framework for creating and managing objects that are singletons or have other specific scope.
To create a singleton with Dagger, you would first define a class that provides the singleton instance. This class is called a "module" in Dagger terminology. Here is an example of a singleton module in Dagger:


@Module 
public class SingletonModule { 
    private static Singleton instance; 

    @Provides 
    @Singleton 
    public Singleton provideSingleton() {
        if (instance == null) {
            instance = new Singleton(); 
        }
        return instance; 
    } 
}

Next, you would define a "component" that uses the module to provide the singleton instance to other classes. Here is an example of a component that uses the above module:


@Component(modules = {SingletonModule.class}) 
public interface SingletonComponent { 
    Singleton getSingleton(); 
}

To use the singleton in your code, you would create an instance of the component and use it to get the singleton instance. Here is an example:


SingletonComponent component = DaggerSingletonComponent.create(); 
Singleton singleton = component.getSingleton();

In this example, the DaggerSingletonComponent class is generated by Dagger at compile time, based on the SingletonComponent interface. The create() method is a static factory method that creates an instance of the component.
By using Dagger to manage the singleton, you can avoid the need to use synchronization to make the singleton thread-safe, as Dagger takes care of this for you. Additionally, Dagger allows you to easily replace the singleton instance with a mock or test double in unit tests, which can make your tests more robust and easier to write.

 

■ "dagger2 singleton"

Dagger 2 is a dependency injection framework for the Java and Android platform. It is not itself a singleton, but rather a framework for creating and managing objects that are singletons or have other specific scope.
To create a singleton with Dagger 2, you would first define a class that provides the singleton instance. This class is called a "module" in Dagger terminology. Here is an example of a singleton module in Dagger 2:


@Module 
public class SingletonModule { 
    private static Singleton instance; 

    @Provides 
    @Singleton 
    public Singleton provideSingleton() { 
        if (instance == null) { 
            instance = new Singleton(); 
        }
        return instance; 
    } 
}

Next, you would define a "component" that uses the module to provide the singleton instance to other classes. Here is an example of a component that uses the above module:


@Component(modules = {SingletonModule.class}) 
public interface SingletonComponent { 
    Singleton getSingleton(); 
}

To use the singleton in your code, you would create an instance of the component and use it to get the singleton instance. Here is an example:


SingletonComponent component = DaggerSingletonComponent.builder().singletonModule(new SingletonModule()).build(); 
Singleton singleton = component.getSingleton();

In this example, the DaggerSingletonComponent class is generated by Dagger at compile time, based on the SingletonComponent interface. The builder() method is a static factory method that creates a builder for the component, which you can use to specify the module(s) to use.
By using Dagger 2 to manage the singleton, you can avoid the need to use synchronization to make the singleton thread-safe, as Dagger takes care of this for you. Additionally, Dagger 2 allows you to easily replace the singleton instance with a mock or test double in unit tests, which can make your tests more robust and easier to write.

 

■ "hilt singleton"

Hilt is a dependency injection framework for the Android platform, built on top of Dagger. It is not itself a singleton, but rather a framework for creating and managing objects that are singletons or have other specific scope.
To create a singleton with Hilt, you would first define a class that provides the singleton instance. This class is called a "module" in Hilt terminology. Here is an example of a singleton module in Hilt:


@Module 
@InstallIn(ApplicationComponent.class) 
public class SingletonModule { 
    private static Singleton instance; 

    @Provides 
    @Singleton 
    public Singleton provideSingleton() { 
        if (instance == null) { 
            instance = new Singleton(); 
        } 
        return instance; 
    } 
}

Next, you would annotate the class that wants to use the singleton with the @Inject annotation. Here is an example:


public class MyClass { 
  @Inject Singleton singleton; 
  // Code that uses the singleton goes here 
}

To use the singleton in your code, you would create an instance of the class and use the singleton. Hilt will automatically inject the singleton into the class when it is created. Here is an example:


MyClass myClass = new MyClass(); 
Singleton singleton = myClass.singleton;

By using Hilt to manage the singleton, you can avoid the need to use synchronization to make the singleton thread-safe, as Hilt takes care of this for you. Additionally, Hilt allows you to easily replace the singleton instance with a mock or test double in unit tests, which can make your tests more robust and easier to write.

 

■ "Flutter singleton"

In Flutter, a singleton is a design pattern that ensures that a class has only one instance and provides a global point of access to it. This is useful when you need to have only one instance of a class for the entire application, such as for managing a shared resource.
To implement a singleton in Flutter, you can use the Singleton class from the singleton_pattern package. Here is an example of how to use it:


import 'package:singleton_pattern/singleton_pattern.dart'; 
class MySingleton extends Singleton<MySingleton> { 
    // Code for your singleton goes here 
}

To use the singleton in your code, you would call the instance property of the class, like this:


MySingleton singleton = MySingleton.instance;

The Singleton class uses Dart's Isolates feature to ensure that the singleton is initialized only once and is thread-safe. This means you do not need to use synchronization to make the singleton thread-safe.

 

■ "Dart singleton"

In Dart, a singleton is a design pattern that ensures that a class has only one instance and provides a global point of access to it. This is useful when you need to have only one instance of a class for the entire application, such as for managing a shared resource.
To implement a singleton in Dart, you can use the Singleton class from the singleton_pattern package. Here is an example of how to use it:


import 'package:singleton_pattern/singleton_pattern.dart'; 
class MySingleton extends Singleton<MySingleton> { 
    // Code for your singleton goes here 
}

To use the singleton in your code, you would call the instance property of the class, like this:


MySingleton singleton = MySingleton.instance;

The Singleton class uses Dart's Isolates feature to ensure that the singleton is initialized only once and is thread-safe. This means you do not need to use synchronization to make the singleton thread-safe.
Alternatively, you can implement a singleton in Dart using a static property and a private constructor. Here is an example:


class MySingleton { 
    static final MySingleton instance = MySingleton._(); 
    MySingleton._(); // Private constructor 
    // Code for your singleton goes here 
}

To use the singleton, you would call the instance property, like this:


MySingleton singleton = MySingleton.instance;

This implementation is not thread-safe, so you would need to use synchronization if multiple threads can access the instance property simultaneously. For example:


class MySingleton { 
    static final MySingleton _instance = MySingleton._(); 
    static MySingleton get instance { 
        return _instance; 
    } 
    MySingleton._(); // Private constructor 
    // Code for your singleton goes here 
}

In this example, the instance property is a getter that uses synchronization to ensure that only one thread can access it at a time. This prevents multiple instances of the class from being created.

 

■ "swift singleton"

In Swift, a singleton is a design pattern that ensures that a class has only one instance and provides a global point of access to it. This is useful when you need to have only one instance of a class for the entire application, such as for managing a shared resource.

To implement a singleton in Swift, you would typically create a static constant property in the class that holds the sole instance of the class, and provide a static method that returns the instance. This method is typically called shared or sharedInstance. Here is an example:


class Singleton {
    static let shared = Singleton()

    private init() {
        // Private initializer to prevent instantiation
    }

    // Code for your singleton goes here
}

To use the singleton, you would call the shared property, like this:


let singleton = Singleton.shared

It is important to note that a singleton in Swift is not thread-safe by default. If multiple threads can access the shared property simultaneously, it is possible for two or more instances of the class to be created. To make the singleton thread-safe, you can use synchronization in the shared property, like this:


class Singleton {
    static let shared: Singleton = {
        let instance = Singleton()
        return instance
    }()

    private init() {
        // Private initializer to prevent instantiation
    }

    // Code for your singleton goes here
}

This ensures that only one thread can execute the shared property at a time, which prevents multiple instances of the class from being created.

 

■ まとめ

日本語で技術的なことを問う場合、英語、カタカナ、区切りなど複雑なので困ったりします。

コードについては、分かる人が見ればすぐに分かります。

どこかで見たような微妙なコードも含まれています。

「とりあえずそれっぽい」ので分からない人には分かりません。

逆に、Google検索と同じように使う側の技量が問われることになりそうです。

👉 Temporary policy: ChatGPT is banned - Meta Stack Overflow hatena-bookmark

👉 Kotlin で書きたい「正しいシングルトン(Singleton)」 hatena-bookmark

👉 チャットできるAI、ChatGPTが「そこまですごくない」理由。見えてしまった限界 | Business Insider Japan hatena-bookmark