搞笑談軟工

March 24 21:45~23:14 ▲Figure 1: Example of elevator specifications foreword The basic functions related to ezSpec and Gherkin have been introduced, and today I will introduce a function that Gherkin does not have: “Specifications for describing parallel behaviors”. Gherkin’s Given, When, Then, And, But these Steps are executed sequentially according to the order in which […]

March 21 18:06~19:30 ▲One Test Method, N green lights foreword The previous episode introduced four ways to write Scenario Outline in ezSpec (please refer to < Using ezSpec to Implement Behavior-Driven Development and Instantiation Requirements (5): Four Ways to Write Scenario Outline >), the Examples used are relatively simple single form. This episode introduces how

March 21 09:47~12:28 ▲Figure 1: Example of Scenario Outline foreword The first two episodes introduce how to write Scenarios in ezSpec (please refer to < Using ezSpec to Implement Behavior-Driven Development and Instantiation Requirements (3): Writing Scenarios and Passing Simple Parameters > and < Using ezSpec to Implement Behavior-Driven Development and Instantiation Requirements (4 ):

March 18 20:27~22:12; March 20 00:00~00:30 foreword After introducing the domain model of ezSpec (please refer to < Using ezSpec to Implement Behavior-Driven Development and Instantiation Requirements (1): Domain Model Introduction> ) and Feature and Story (please refer to < Using ezSpec to Implement Behavior-Driven Development and Instantiation Requirements (2) : Feature and Story >),

March 15 08:57~11:00; 20:02~08:19 ▲Use ezSpec to write the instruction file of ezSpec foreword The previous episode < Using ezSpec to Implement Behavior-Driven Development and Instantiation Requirements (1): Domain Model Introduction > mentioned that Feature is the largest unit used by Gherkin to describe requirements. Today we will introduce how to write Feature in ezSpec.

March 14 18:10~19:02; 20:28~23:23 ▲Figure 1: ezSpec domain model foreword Behavior-Driven Development (BDD) and Specification by Example are two mainstream test-driven development methods. By discussing requirements (collaborative modeling) with domain experts or stakeholders, as well as specific examples representing requirements, and expressing them in automated test cases, the effect of Living Documentation can be achieved.

February 07 20:57~22:15 ▲ChatGPT official website home screen foreword ChatGPT has attracted a lot of attention since it was launched in November last year. Originally, Teddy had no idea about this topic, but last Friday, Mr. Zheng (Teddy’s supervisor) shared his experience of using ChatGPT at the meeting, which aroused Teddy’s attention. Interest in ChatGPT.

January 04 00:00~01:10 foreword The Lunar New Year will be celebrated within a few days of work in January this year. At the end of last year, when arranging Teddy Software’s 2023 class schedule, I simply vacated the entire January. Originally, I wanted to find an opportunity to sneak out to play abroad again, but

August 25 17:43~18:21 foreword Over the past two years, I have been mobbing with the ezKanban team. The back-end has applied Domain-Driven Design (DDD), Clean Architecture, Event Sourcing, CQRS, TDD, Design By Contract (DBC), and Living Documentation. Almost all of the back-end architecture started at the beginning All designed by Teddy. This is normal, because

August 17 21:54~22:49 ▲Figure 1: Repository interface foreword In < I may not use you, Event Sourcing + CQRS? ! (Top) > Teddy mentioned that Event Sourcing is not more complicated than State Sourcing when writing the model (Write Model/Command Side), or even simpler. But things are usually one or the other. Writing is relatively

August 16 10:03~11:33 ▲Figure 1: Clean Architecture four-tier architecture foreword Last weekend, I finished the first group of [ Event Tracing and Command Query Responsibility Separation Architecture Implementation Class ], and a veteran student who had known each other for nearly ten years told Teddy: “This is the most difficult course I have taken in

July 26 15:52~16:39 ▲Figure 1: Optimistic lock test case foreword This series of articles was originally written by Teddy in order to create a course example of [ Event Sourcing and Command Query Responsibility Separation Architecture Implementation Class ]. The course example has been completed, and the serialization of this series of articles has ended.

July 19 09:07~10:58 ▲Figure 1: ” Get Your Hands Dirty on Clean Architecture ” program example directory structure foreword In September 2021, Teddy wrote a book review for the book ” Get Your Hands Dirty on Clean Architecture ” (please refer to ＜ [One less book] Get Your Hands Dirty on Clean Architecture ＞). A