実務でぶつかる疑問（こんな場合どうするのよ！）を解決してくれる書籍でした。
deeplに突っ込んだのか？という謎の言い回しがないのも非常に良かったです。非常に読みやすく翻訳されています。
また最近は、読んだだけどと忘れてしまうので、最近は付箋を貼りながら読書するようにしています。

読もうと思ったきっかけや感想を書きたかったのですが、文章がまとまらなかったのでこれくらいにします。
30分で400-800文字くらいサラッと書けるようになりたいな。

2023-09-03

SpringBootで実行可能jarを作る方法

Spring Boot

hogehohe.jarにメイン・マニフェスト属性がありませんというエラーが出てちょっとハマったので

pomに以下を追加したら解決した *1

        <plugins>
            <plugin>
                <groupId>org.springframework.boot</groupId>
                <artifactId>spring-boot-maven-plugin</artifactId>
            </plugin>
        </plugins>

spring.pleiades.io

2023-08-20

アノテーションベース Spring DIの復習

Spring Java

はじめに
- 学習内容
- 環境
やっていく
- DIとは？
  - アノテーションベースで実装してみる
  - ApplicationContextからBeanを取得する
まとめ
引用

はじめに

普段はSpring Bootを利用して開発している DI周りは困ったら調べるくらいでしかないので、ちょっと復習しようと思う

学習内容

この辺に触れていく

@Component
@Autowire
@Configuration
@Bean
AnnotationConfigApplicationContext

環境

java周り

Apache Maven 3.9.3 (21122926829f1ead511c958d89bd2f672198ae9f)
Maven home: C:\Program Files\apache-maven-3.9.3
Java version: 17.0.2, vendor: Oracle Corporation, runtime: C:\Program Files\jdk-17.0.2
Default locale: ja_JP, platform encoding: MS932
OS name: "windows 11", version: "10.0", arch: "amd64", family: "windows"

pom

  <parent>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-parent</artifactId>
    <version>3.1.0</version>
  </parent>
  <dependencies>
    <dependency>
      <groupId>org.springframework.boot</groupId>
      <artifactId>spring-boot-starter-web</artifactId>
    </dependency>
    <dependency>
      <groupId>org.projectlombok</groupId>
      <artifactId>lombok</artifactId>
      <optional>true</optional>
    </dependency>
  </dependencies>

RestContollerを使って動作確認をしていく

やっていく

DIとは？

依存性の注入という単語で色々な方が解説されているので、割愛します。公式の文章が気になったので引用します*1

この章では、制御の反転（IoC）原則の Spring Framework 実装について説明します。IoC は、依存性注入（DI）とも呼ばれます。これは、コンストラクター引数、ファクトリメソッドへの引数、ファクトリメソッドが構築または返された後にオブジェクトインスタンスに設定されるプロパティを通じてのみ、オブジェクトが依存関係（つまり、操作する他のオブジェクト）を定義するプロセスです。コンテナーは、Bean を作成するときにそれらの依存関係を注入します。このプロセスは、基本的に、クラスの直接構築または Service Locator パターンなどのメカニズムを使用して、Bean 自身がその依存関係のインスタンス化や場所を制御することの逆（そのため、Inversion of Control という名前）です。めちゃめちゃ分かりづらいですが、IoC≒DIということまた、違いは次のブログのまとめがわかりやすかったです *2 ※IoCという概念を公式のドキュメントを読んで初めて知りました

アノテーションベースで実装してみる

model

@Data
public class Employee {
    @NonNull
    private final String name;
    @NonNull
    private final String id;
}

Controller

@RestController
public class EmployeeController {

    // @Autowired
    private final EmployeeServiceInterface employeeService;

    // コンストラクタインジェクション
    EmployeeController(EmployeeServiceInterface employeeService){
        this.employeeService = employeeService;
    }

    @RequestMapping("/getEmployee")
    public Employee getEmployee(){
        return employeeService.get();
    }
}

Service

public interface EmployeeServiceInterface {
    public Employee get();
}

@Service // Beanを登録する
public class EmployeeServiceImpl implements EmployeeServiceInterface {
    @Override
    public Employee get() {
        return new Employee("Admin","1");
    }
}

curlでアクセス、こんな感じで取れる

$ curl http://localhost:8080/getEmployee

Content           : {"name":"Admin","id":"1"}

@Seriveをつけることで、該当のクラスがDIコンテナに登録される（細かい話をすると@SpringBootApplicationが付与されたクラスと同じ階層か、配下のパッケージにDIしたいクラスが存在する必要がある）
本来インスタンス化したいクラス変数に＠Autowiredを付与することでも、DIしたクラスの代入が可能となるが
公式によるとコンストラクタインジェクションが推奨されているので、このように実装した*3

ApplicationContextからBeanを取得する

新しくConfigクラスを追加する

@Configuration
public class MyConfig {

    @Bean
    Employee getEmployee() {
        return new Employee("MrMyConfig", "2");
    }
}

あんまり良い例ではないけど、Controllerを修正してApplicationContextからBeanを取得する

 public class EmployeeController {

     // @Autowired
-    private final EmployeeServiceInterface employeeService;
+//    private final EmployeeServiceInterface employeeService;

     // コンストラクタインジェクション
-    EmployeeController(EmployeeServiceInterface employeeService){
-        this.employeeService = employeeService;
-    }
+//    EmployeeController(EmployeeServiceInterface employeeService){
+//        this.employeeService = employeeService;
+//    }

     @RequestMapping("/getEmployee")
     public Employee getEmployee(){
-        return employeeService.get();
+//        return employeeService.get();
+        ApplicationContext context = new AnnotationConfigApplicationContext(MyConfig.class);
+        return context.getBean(Employee.class);
     }
 }

生成した社員インスタンスをDIコンテナに格納、Applicationコンテキストからgetしてくる
本来のConfigクラスの利用方法として、自作コードではなく外部ライブラリの機能をDIしたい場合に利用する
例えば、thymeleafを利用したSpring MVCのアプリを作成している場合、以下のような利用方法になる

@Configuration
public class JavaConfig {

    @Bean
    public ModelMapper modelMapper(){
        return new ModelMapper();
    }

    @Bean
    public PasswordEncoder passwordEncoder() {
        return new BCryptPasswordEncoder();
    }
}

Configクラスでインスタンス化した社員オブジェクトが取得できることがわかる

$ curl http://localhost:8080/getEmployee

Content           : {"name":"MrMyConfig","id":"2"}

まとめ

なんか知っていることを改めて整理して書くことの難しさを感じた出てくる単語や概念をすべて記載すると文章量が増えて分かりづらくなる結果、誰向けに書いているのか分からなくなった（振り返りなので、これでいいかもしれないけど）

また、公式のドキュメントを見ていると色々な発見があったので、また備忘としてブログにまとめたい

引用

*1 Spring IoC コンテナーと Bean の導入 ::Spring Framework - リファレンス

*2 IoCコンテナ＆AOPについて - HackMD

*3 依存性注入 :: Spring Framework - リファレンス

コンストラクター vs setter、どちらの DI を選ぶ？

2023-08-19

10月までに学習すること

雑記

以下について復習

Spring DI：このへん

spring.pleiades.io

Springのプロファイル機能：たぶん知りたいのはこの辺

spring.pleiades.io

maven マルチモジュールプロジェクトの構築と管理：たぶんこのへん

spring.io

2023-08-17

「知識ゼロから学ぶソフトウェアテスト【改訂版】」を読んだ

テスト技術書

www.shoeisha.co.jp

はじめに
- 前提
- なぜ読もうと思ったのか
感想
まとめ

はじめに

忘れないために読んだ感想、心に止めて留めておきたい内容を書いていく、要約ではない

前提

このブログを書いた時点での私のレベル感
テストに関する知識は記憶にあるかぎりでは書籍を1冊

【この1冊でよくわかる】ソフトウェアテストの教科書―品質を決定づけるテスト工程の基本と実践

また、ヒンシツ大学の体験型講座の機能テストと非機能テストの講座を受講したことがある

なぜ読もうと思ったのか

職場の同僚が、ソフトウェアテストの歩き方　みたいなマインドマップをslackに貼っていて、そのスタートがこの本だった
※多分 SlideShareで公開されているものだった気がする
スクラムだ！TDDだ！という気運から、テストに関する知見をもっと深めねばと感じていたので買ってみたという運び

感想

リファクタリングとユニットテストの本質について

TDDの本質は確実に品質保証するというより、スピードを持って開発し、そして変更に対して耐性を持つことです。

TDDの説明をされると、ユニットテストをちゃんと組んでいれば結合テストはそこそこでいいよね？というように聞こえていた
その違和感が解消された

探索的テスト

探索的テストとはソフトウェアの理解とテスト設計とテスト実行を同時に行うテストである

探索的テストという単語を初めて知った
また、自身が結合試験などを行うときにやっていた手法がこれに当たることを理解した
テストケースを書いていない（工数的に報告しずらい）ので、こっそりやっていた
これからは工数をもらって作業しよう
※現職では、スクラムを採用しているため、開発とテストは同じメンバーが担当する

信頼性について

いわゆるバグ曲線ってあんまり意味ないのでは？という話
バグMTBFの話は面白かったので、メトリクスを取って見たいと思う

コストと品質のバランス

現職では考慮する必要が薄い話だったが、心に止めて置きたい話だったのでメモ

「できません」と言えない日本人

テストというよりもスケジュール管理と交渉の話
なんか、この手の交渉を上手に通す方法があれば知りたい

テスト自動化の罠

テスト自動化は以外と失敗するというお話
向き不向きがあるので、自動化に向いているテストをしましょう
また、UIを含む回帰テストは自動化に向かない、保守コストが高すぎるから

まとめ

テスト手法にばっかり目が向いていたが、体型的にソフトウェアテストについて学ぶことができた気がする
ここから気になった方面（テスト手法や自動化、テスト計画etc）に知見を伸ばして行くのが正解だったなと感じる
文章も硬すぎず（柔らかすぎるくらい）非常に読みやすかった。私には合っていた。