Red-Green-Refactor In Short Cycles! 1. Write failing test 2. Make it pass 3. Make it good Fabian Schmengler /> 9 Common misconceptions about TDD @fschmengler
Red-Green-Refactor In Short Cycles! 1. Write failing test ⬅ one little test at at time 2. Make it pass 3. Make it good Fabian Schmengler /> 9 Common misconceptions about TDD @fschmengler
Red-Green-Refactor In Short Cycles! 1. Write failing test ⬅ one little test at at time 2. Make it pass ⬅ stupid hacky solution 3. Make it good Fabian Schmengler /> 9 Common misconceptions about TDD @fschmengler
Red-Green-Refactor In Short Cycles! 1. Write failing test ⬅ one little test at at time 2. Make it pass ⬅ stupid hacky solution 3. Make it good ⬅ well designed solution Fabian Schmengler /> 9 Common misconceptions about TDD @fschmengler
Other ways to experiment Exploratory tests Use failing assertions to see real results of unknown operation. e.g.: $this->assertEquals([[], [], []], $result); REPL (Read-Execute-Print-Loop) JS: browser console PHP: n98-magerun2 dev:console Fabian Schmengler /> 9 Common misconceptions about TDD @fschmengler
Iterative vs. Incremental Always refactor Started with a stupid solution Design evolves through refactoring Fabian Schmengler /> 9 Common misconceptions about TDD @fschmengler
Changeability & Replacability GeePaw Hill @GeePawHill If I change out of my galoshes and in to my tennis shoes, I'm preparing to move faster. Sure, I could run the race in my galoshes. Sure, it will take me a few seconds to take them off. But I'm betting that the cost of changing the shoes will be more than made up during the race. 9 13:32 - 18. Jan. 2019 Weitere T weets von GeePaw Hill ansehen GeePaw Hill @GeePawHill · 18. Jan. 2019 Antwort an @GeePawHill It really is just that simple, not rocket science but basic efficiency: people make this kind of decision every day, where they enhance their performance by doing things that are not themselves performing. Fabian Schmengler /> 9 Common misconceptions about TDD @fschmengler
Test Driven A way to write code Tests are means to an end (and a welcome side effect) Development ⬆ Fabian Schmengler /> 9 Common misconceptions about TDD @fschmengler
TDD does not replace Requirement analysis Domain Modeling System Design API Design => WHAT to build Architects are not becoming unemployed Fabian Schmengler /> 9 Common misconceptions about TDD @fschmengler
Isolation Isolation From WHAT? External resources: certainly Framework: mostly Except for integration tests Libraries: rather not No implementation details. Fabian Schmengler /> 9 Common misconceptions about TDD @fschmengler
Avoid the Mocking Hell Keep Magento dependencies to a minimum Mock/stub service contracts (API interfaces), not concrete classes Write adapters for complex or insu cient API Mock or fake those Fabian Schmengler /> 9 Common misconceptions about TDD @fschmengler
Unit Test Subject Public API of components e.g. Service as Facade, and its return types No unit tests for framework integration layer: Controllers Plugins Observers Blocks Resource Models, Repositories Those remain dumb and use our components. Fabian Schmengler /> 9 Common misconceptions about TDD @fschmengler
Unit Test Test behavior, not implementation 1 Test Case != 1 Class 1 Test != 1 Method Fabian Schmengler /> 9 Common misconceptions about TDD @fschmengler
Example feature: Subscriptions Orders can be turned into subscriptions Subsequent orders are placed automatically Behavior to test A subscription is created if an order has been marked as subscription during checkout Orders are created for active subscriptions with due date Fabian Schmengler /> 9 Common misconceptions about TDD @fschmengler
Exception Testing implementation details can aid development and small scale refactoring. BUT those tests can be thrown away when their job is done! Otherwise they stay only as maintenance burden. Let them go! Fabian Schmengler /> 9 Common misconceptions about TDD @fschmengler
TDD Helps with code design Focus on developers BDD/ATDD Helps with requirement analysis Focus on users Fabian Schmengler /> 9 Common misconceptions about TDD @fschmengler
Test Behavior Ideas are not contradictional! With TDD we should test behavior as well And why not both? Fabian Schmengler /> 9 Common misconceptions about TDD @fschmengler
Tests in Natural Language Who is really writing their tests together with the customer? Expressive test code is possible without Gherkin Fabian Schmengler /> 9 Common misconceptions about TDD @fschmengler
Gherkin Scenario 1: Refunded items should be returned to stock Given that a customer previously bought a black sweater from me And I have three black sweaters in stock. When they return the black sweater for a refund Then I should have four black sweaters in stock. PHPUnit public function test_refunded_items_should_be_returned_to_stock() { $this->given_that_a_customer_previously_bought_a_black_sweater_from_me(); $this->and_I_have_three_black_sweaters_in_stock(); $this->when_they_return_the_black_sweater_for_a_refund(); $this->then_I_should_have_four_black_sweaters_in_stock(); } Fabian Schmengler /> 9 Common misconceptions about TDD @fschmengler
Coming soon when it's done: Test Driven Magento by Example https://tddwizard.com/ @fschmengler Fabian Schmengler /> 9 Common misconceptions about TDD @fschmengler
schmengler
hirokiotsuka
sumiren
odasho
blue_goheimochi
kako351
masashi_sutou
iotengineer22
nikkei_engineer_recruiting
kubukoz
tatematsu_san
dskst
oekazuma
jensimmons
robhawkes
malarkey
scottboms
carmenintech
kneath
smashingmag
marcduiker
lara
aki_iinuma
eileencodes
brad_frost