レベル1完了後

必ずテストコードを作成しますか?

テストコードの作成には多くの時間がかかります.また、テストコードは本番コードに影響を与えません.それでもテストコードを書くべきですか?私はテストコードの第1級を書くとき、いつも消極的な考えを持っています.コードがうまく書けば、テストを書く必要はないと思います.

まず、コードを書く確率は小さい.正しいコードを作成しても、画面側で多くのエラーが発生します.したがって、テストコードを作成するときに、すべての機能のエラーを一目で見ることができます.

コラボレーションと考えられ、私が作成したコードが他の開発者によってテストされた場合は、画面上でテストを1つずつ行う手間を省くことができます.

したがって,テストコードの作成コストは開発者自身がテストするコストよりも低い.また、プロジェクトの規模がもう少し大きくなれば、このコストを感じることができます.機能の増加と機能間の相互関係の増加に伴い、直接テストのコストは2倍に増加するため、テストの導入は不可欠であるようだ.
開発者は重複するコードが好きではありません.したがって,テストコードを記述する際にキーワードを用いて重複コードを減らすことができる.

before()
before()は、すべてのテストの前に一度実行する必要があるロジックを追加することをお勧めします.

describe("상품 관리 탭 테스트", () => {

	before(() => {
	// 로그인 로직
		cy.visit("http://localhost:9000/#product");
		cy.get(".member-login-button").click();
		cy.get(".member-info-input").eq(0).type("[email protected]");
		cy.get(".member-info-input").eq(1).type("examle!");
		cy.get(".member-confirm-button").click();
		
		cy.waitUntil(() => cy.location('hash').should('eq', '#product'));
	})

	it("자판기에 상품 추가가 기능하다", () => {     
	    cy.get("@productNameInput").type("사이다");
	    cy.get("@productPriceInput").type(PRODUCT.MAX_PRICE);
	    cy.get("@productQuantityInput").type(PRODUCT.MAX_QUANTITY);
	    cy.get("#product-add-button").click();
	
	    cy.get(".product-name").should("have.text", "사이다");
	 });
});

beforeEach()
テストコードは、汎用機能をテストするときにグループテストを行うことが望ましい.describe()に複数のテストがある場合は、各テストが実行される前にbeforeEach()の論理が実行され、テストが行われます.

describe("상품 관리 탭 테스트", () => {

	beforeEach(() => {
    cy.get(".product-control-input").eq(0).as("productNameInput");
    cy.get(".product-control-input").eq(1).as("productPriceInput");
    cy.get(".product-control-input").eq(2).as("productQuantityInput");
  })

	it("자판기에 상품 추가가 기능하다", () => {     
	    cy.get("@productNameInput").type("사이다");
	    cy.get("@productPriceInput").type(PRODUCT.MAX_PRICE);
	    cy.get("@productQuantityInput").type(PRODUCT.MAX_QUANTITY);
	    cy.get("#product-add-button").click();
	
	    cy.get(".product-name").should("have.text", "사이다");
	 });
});

タイプスクリプトを忘れられない理由

常にタスク生産コードを作成する前に、タスクを全体的に設計し、設計の方向に従ってコードを作成します.タイプスクリプトを使用している場合は、ロールに基づいてクラスを設計して作業を設計できます.クラスが行うべきことを設計するときに、クラスに正しい役割があるかどうかを判断できます.
ライブラリ、フレームワーク、ツールを使用する唯一の理由を見つけてから、私はそれに興味を持っています.自動販売機タスクからタイプスクリプトでタスクを完了し、JavaScriptで実現した個人プロジェクトの再設計に至るまで、タイプスクリプトが恋しいです.JavaScriptは高度に自由な言語です.自由度が高ければ高いほど、責任は大きくなる.すべての責任は開発者が負う.タイプスクリプトの導入の責任を軽減できます.

タイプのスクリプトは静的タイプ言語なので、JavaScriptのように動的タイプ言語の値が変化することを心配する必要はありません.

型のスクリプトは、コンパイル時にJavaScriptコードのエラーをキャプチャします.これにより、コードの実行後にエラーが発生する確率が減少します.

タイプのスクリプトは漸進的です.タイプスクリプトに移行できるのは、開発者が必要とする場合のみです.

do X、doユーザーが考慮しなければならない

Front Engineer、略称FE開発者
私はずっとFとEの中のEに専念して、勉強もEの実力のために多くの努力をしました.そのため、タスクの中で、ユーザーは私の唯一なので、私はFを気にしないで、世界で気前の良いユーザーだけのサービスを作成しました.しかし、現実世界にはクレイジーなユーザーがたくさんいます.私も同じです.私が使っている英語学習サービスでは、正解ボタンがあれば、正解を提出するときに狂ったように正解ボタンをクリックし、正解を提出した瞬間に私が選んだ答えを変える動作をします.発売されて間もないサービスなので、狂ったように正解ボタンを押すと、レベルがバーを通って上昇するなどのエラーが発生します.
ボコのFに対するフィードバックから、私がずっと無視していたことを再び思い出した.私のサービスに寛容で、他のサービスでクレイジーなユーザーになった私.
Tosを例にとると、Tosでは、あるコンテンツにユーザーの同意が必要な場合、私はためらうことなくすべての条項を受け入れることができます.このようにコンテンツをストリーミングに使用することにユーザーが同意すれば、ユーザーの移行率は非常に低いと思います.そのため、このレベルの最後のタスクである自動販売機のタスクでは、ユーザーに友好的なサービスを提供できる良いタスクだと思います.私はそのためにたゆまぬ努力をしました.たとえば、「コストの追加」ページでは、ユーザーが入力する値に多くの制限があります.したがって、inputで値を作成してマウス(次のinputに移動)をクリックすると、入力値の有効性を確認し、inputの下部に欠落した値が表示されます.検証に失敗した理由に基づいてテキストを表示し、成功したときにユーザーにテキストを表示します.
便利で友好的なユーザーサービスを作成するには、開発者が大きな課題に直面しています.これらの困難を克服してこそ、ユーザーに便利なサービスを提供し、開発者に低ユーザー流失率のサービスを提供することができます.

浦項製鉄~