I read test driven development

I have started to seriously learn about TDD, which I have been interested in for a long time.

One of the reasons I wanted to start TDD wasTDD Changed My Life I once read an article called.

TDD has a learning curve, and if you stick with it, even though you're writing tests, you'll be able to implement them faster than if you didn't.

The experience was written.

TDD has a learning curve, and while you're climbing that learning curve, it can and frequently does add 15% — 35% to implementation times. But somewhere around the 2-years in mark, something magical started to happen: I started coding faster with unit tests than I ever did without them.

https://medium.com/javascript-scene/tdd-changed-my-life-5af0ce099f80

Doesn't this look like a lot of fun? I really wanted to try it myself.

So, let's read about "Test Driven Development".

Chapter 1 Temporary implementation

We start from the basic flow of TDD.

• First, make a TODO list
• When you start writing code, start with tests, not implementation.
  • "The perfect interface for your needs"imagine
    • Work backwards from the behavior when calling from outside.
• Even dirty test code (including implementation code) will still compile.
• Verify that the test fails
• Write an implementation that passes the test
• Refactor and remove duplicates

Chapter 2. Obvious implementation

In Chapter 2, we will write the tests first and then implement the code.

However, if you clearly know how to implement it, you don't have to write the return value all over the place like in Chapter 1."Write the implementation you know as is"This is the content.

If it's easy to implement

• "Obvious implementation" modeProceed with and if it gets difficult
• "Temporary implementation" modeImplement little by little -> Eliminate duplication by refactoring

Chapter 3 Triangulation

In Chapter 3, we will implement the Dollar object using the Value Object pattern to explain the technique called "triangulation" used in TDD.

Triangulation is a method of writing tests for multiple variations to generalize your code.

• Use when you don't know how to refactor

Value Object pattern

• Advantage: No need to worry about alias references
  • The value object pattern seems to be a good way to avoid the alias reference problem...?
  • Let's organize Value Objects
  • Alias reference questions and value objects

• Constraint: The value of instance variables set in the constructor must not change.
• Operation: return new object
• Operation: equals method is implemented
  • For value identity comparison

Chapter 4: Intention Test

Look at the test and modify it to make it easier to understand what the target function returns.

• Modified so that even if the test passes, it can be understood from the documentation point of view that it "returns an object"

• As a side effect, by making the amount property private, it is no longer necessary to expose unnecessary variables to the outside world.

Chapter 5: When you dare to break a principle

I'm going to start developing "$5+10CHF=$10" on the TODO list.

• Since the above is a TODO list and has a large granularity, I decided to write a test for the Franc class first.
  • 5CHF*2=10CHF
• Breaking good design principles to gain development speed
  • (=copy and paste)
  • To the point where you know what state the new feature is in
  • (=Only during the following 3 steps)
    • write a test
    • pass through the compiler
    • Run the test and check for failures

Chapter 6: If you notice a lack of testing

Designed to make Money a parent class and inherit it in order to make Dollar and Franc commonI came up with the following and amended the code accordingly.

• In the modification, I noticed that there is a test for comparing Dollars, but there is no test for comparing Francs.
  • (=notice the lack of tests)
• Regarding the deficiencies I noticed,Add a test
  • Add tests later if needed
• Modify and generalize the added tests so that they pass.

Chapter 7 Translating Doubt into Test

If you have questions while writing code, test them.This is the story.

• Verify whether Franc and Dollar can be compared correctly
  • In terms of whether they are the same, I would like it to be False.
  • But it actually turns out to be True.
    • This is a common part in the parent class (Money class), so of course...
  • Solve the problem by using the getClass method to get the class that is being called and include it in the conditions for matching or being the same.

Chapter 8. Hide implementation

We will standardize the times method for Dollar and Franc.

• Define a factory method called dollar method on Money.
  • The dollar method creates a new Dollar instance and returns it.
    • That's why it's a Factory...
• Separate the existence of subclasses from testsState of “hiding implementation”to make

Chapter 9 Adjusting stride length

I want to standardize the subclasses (Dollar and Franc), so I will try various details..

• Let's create a Currency method: First, return the currency name (string)
• I want to bring the implementation of Dollar and Franc closer together so that they are the same.
  • Just give the currency name to the instance variable and return it using the Currency method.
  • In the above, the implementation of the Currency method is exactly the same for Dollar and Franc.
    • So, raise the implementation of the Currency method to the parent class
    • Furthermore, the constructors for Dollar and Money have become quite similar, so it seems likely that these two can be made common.
    • By specifying Currency information (currently currency name information) in the parent class at construction time, the constructor for child classes can be shared.
    • Make the constructor common and move it to the parent class (Money class)

Up to this point, we have even been able to standardize the constructor for subclasses!

Chapter 10 Ask the test

I want to get rid of subclasses (Dollar and Franc) and make Money all the same, so I will work on standardizing the times method.

• Try making the return value of times a new Money class inline.
  • We just used the factory method in the previous chapter...
• Thanks to the above, the times method was also elevated to the parent class.
  • Parent class is no longer abstract
• Exceptional handling when an error occurs
  • There is no need to write test code to rewrite code for debugging (debug output such as print)
    • I tried overriding toString to make the debug output easier to understand.
      • As a result, it's not very clear...
  • Cause: Previously implementedWhere getClass() was used to check if the currencies are the same
    • By changing the code design"Currency is specified by class"An error occurred in a part that depended on this design.
  • handle: Revert the changes that made the test red and return it to the green bar
  • Solution 2: Write another test and change the implementation to pass it.
    • Even if the classes are different, if the amount and currency match, they are the same.Test to make sure
    • Instead of comparing classes with getClass(),Implementation changed to compare currency() values
• In the end, I was able to eliminate the subclasses and consolidate them into one Money class.

Chapter 11 Delete when no longer needed

Delete the subclasses and related tests that are no longer needed due to the refactoring in the previous chapter.

• Delete the Dollar class

• Delete the test written to verify the franc method that returned a Franc object.
• Written with the assumption that multiple subclasses exist.Remove testDifferentClassEquality
• Also delete the Franc object
  • Since the above test that referred to the Franc object is no longer
• Multiplying Dollar and Franc was originally done in a separate class, but now we use currency in the same class, so we also delete testFrancMultiplication.

Chapter 12 Design and Metaphor

My TODO list has become cluttered, so I moved unresolved items to a new list.

• Write $5+$5=10 tests
  • As a small step to implement 5$+10CHF=10$

• “How to express calculations between multiple currencies”difficult
  • The constraint of ``I want to write code that makes it almost impossible to notice that it is handling multiple currencies''for

• Imposter objectuse
  • An object that behaves like Money, but represents the sum of two Moneys

If an object doesn't behave the way you want it to, just implement a new object with the same external protocol (methods) to do the job.

• Expression object is Imposterbecomes

• Since the Expression object was likely to be an important function, I separated it from the Bank object to avoid bloat.

• Bank object: Here we just execute the reduce method

• reduce method: Method to apply exchange rate to Expression

Chapter 13. Testing to guide implementation

In order to complete the implementation of $5+$5=$10, we will implement the Bank object that we wrote in detail last time.

• Originally it is necessary to return the result of 5$+5$ (Money object of 10$)
  • Right now I'm writing in a solid line to return Money.dollar(10) (the result itself)
• First, write a test such that $5+$5 returns a Money object.
  • Are you shortening your stride?
  • testPlusReturnSum
  • Tests that are deeply related to internal implementation rather than external behavior tests
    • Scheduled to disappear soon
    • I was using the plus method that returned a Money object, so an error occurred.
      • Modify the plus method to return a Sum object
        • Of course, the Sum object has no implementation, so we define a constructor.
        • Sum object implements Expression Interface
          • (Imposter (an object that behaves like Money, but represents the sum of Money))
• Write a test for the reduce method
  • Create testReduceSum limited to the addition sum test
  • Requirement: Return a Money with the amount of the addition result.
  • Transfer part of reduce from Bank to Sum
    • Therefore, it is necessary to test Bank.reduce(Money)
      • By the way, Bank.reduce is a wrapper for Expression's reduce.
    • "Explicit class checking should be replaced with polymorphism"
      • Add reduce method to Expression interface

Chapter 14 Learning Tests and Regression Tests

Let's finally convert and convert the Money object.

• Create addRate
  • This is for registering USD and CHF for now. Kara at this point.
• Implementation of Money.reduce()
  • As a matter of urgency, when converting from Swiss Franc to USD, rate is hardcoded to 2 (P.102)
  • With the above implementation, the Money object will know the exchange rate.
    • The exchange rate should be the responsibility of the Bank object.
      • "Pass the Bank object containing the exchange rate as an argument to reduce"seems to be correct (Object delegationkana? )
      • Create rate as Bank's rate method, and when using Money's reduce, ask Bank for rate.
  • The 2 used to calculate the rate is the magic number, so eliminate it.
    • I tried to use a hash table, but there are some concerns.
      • Can an array containing two currency names be used as a hash table key?
      • Can the equals method correctly compare the equality of elements in an array?
    • I write a test to confirm the above two points, but it ends up failing, so I create a Pair class.
      • To use a Pair instance as a hash table key, you will need the equals method and hashcode method, but this is a refactoring process, soI also don't write tests for the Pair class.
      • Created a rate hash table using the Pair object as a key using the HashMap class.
      • An unexpected error occurred here, but I resolved the error by writing a regression test.

Chapter 15: Leave it to the test and leave it to the compiler

I'm finally at the stage of writing the $5+10CHF test.

• When I write a test normally, an error occurs in the plus method of the Money object.
  • I changed what was originally written using an Expression object to a more specific Money object.

• The cause is that the augend and the addition number are not reduced (unified currency) in the reduce method of the Sum object, so fix it.
• Once you've done this up to this point, although you're writing in Money, you'll come across parts that can be replaced with more abstract Expressions, so replace them.

It seems that Money can be generalized to Expression.

Chapter 16: Testing for future readers

We performed empty implementation in the previous chapter.plus method of Sum objectWe will implement it properly. After thattimes methodtoo.

• While writing a test for the plus method, I use new Sum to make the intent easier to understand.
  • The plus method performs new Sum internally, so there is no need to write new Sum on the test side...
• Next, implement the times method
  • Write a test and declare times method in Expression interface
• Write a test to check that $5+$5 returns Money
  • but,Using instanceof to see the state of the class itself
    • ＝It has become a test that goes into implementation.
  • "This task is an experiment," so I'll pretend there was no test...

Chapter 17 Overall review of multilateral currencies

Now that we have implemented multinational currencies, let's look back.

• What happens from here?
  • The question “Are there enough tests?”can throw
    • Try writing a test that says, “This is not how it should work.”
  • When your TODO list is empty, it's a good time to revise your design.
    • Is there a discrepancy between the design words and concepts?
    • Are there any duplications that are difficult to eliminate with the current design?
• metaphor
  • By rewriting the same design and implementation over and over again, you may discover new insights and surprises.
    • After rewriting it many times, I think I came up with a metaphor for an expression.
      • From the author's own experience

• JUnit usage through multi-country currency sample creation
  • 125 test runs
  • Run test once per minute
• code metrics
  • Number of lines in classes and methods, etc.
  • The test code is long (about twice the product code) and the number of lines per method is short overall.
    • The number of lines per method in the product code is 4.5
    • The number of lines of test code per method is 7.8
• process
  • Add a small test
  • Run all tests and make sure there are failures
  • change
  • Run all tests again and make sure they all pass
  • Refactor and remove duplicates
• test quality
  • "Statement coverage is not a sufficient measure of test quality, but it is a starting point."
  • Defect injection: "If you change the meaning of any line of product code, the test must fail."
  • "Instead of covering all input combinations by adding more tests, cover more combinations by keeping the same tests but using less code."
• final retrospective
  • Preliminary implementation, triangulation, and obvious implementation
  • Eliminate duplication between tests and code
  • Ability to control gaps between tests

Chapter 18: Small steps towards xUnit

The development of the multinational currency object ends in Chapter 17, and the development of the test tool itself begins here.

• A program that outputs true if a test method is called and false if it is not called.
  • Prepare flags for test cases
  • Check that the flag is false before running the test method
  • When the test method runs, check that the flag is true
  • The name is WasRun. This is a test that answers whether the method ran or not.
  • Currently verified using Python's built-in assert method
• If you can execute the run method, try refactoring it.
  • That said, haven't you refactored it?
• Working on dynamic invocation of testMethod
  • "Attribute indicating test case nameIf you query the object and call the returned object like a function, the method will be called.
    • Pluggable Selector pattern…?
    • Just add () to the variable containing the method name to execute the method...
      • That's itIt's dynamic. It feels like metaprogramming...
      • I feel like something like this existed in PHP, but I don't think it was recommended much...
• I think we can do one more refactor.
  • TDD is"You can proceed while actually checking the behavior to be generalized, so you don't have to worry about it only in your head."
  • The WasRun class ended up doing two jobs.
    • The job of recording whether a method has been invoked
    • The job of dynamically calling a test method
  • Separate into parent class TestCase
    • name attribute, raise run method to parent class

Chapter 19 Preparation

As a preliminary preparation, we will create a setUp method for the test.

• When comparing performance and independence,Decide on specifications to create (setUp) a new object for each test, emphasizing independence.

• Eliminated the WasRun class constructor using the setUp method (simplified it)
• The setUp method was used to create a WasRun class instance for each method in TestCaseTest, but it was now common.

Chapter 20 Cleaning up

If you add tearDown methods in addition to the setUp method, it will become difficult to manage using only flags. Therefore, we will implement it by recording the methods called in the log.

• Write the setUp method of the WasRun class to output what is currently being done to the log.
• The testSetup method now contains the contents of multiple tests, soChange to testTemplateMethod
• Testing tearDown -> Implementation
  • If you do not implement tearDown empty in the parent testCase class, an error will occur, so implement
  • Since the run method that uses tearDown is in the parent class, an error will occur if tearDown itself is not in the parent.

Chapter 21 Counting

We will start working on the test result reporting function.

• In order for tearDown to work properly even if an error occurs, it is necessary to catch the exception.
• The scope is too large to collect and report all test case results.
  • As a next best option,Make the run method of the TestCase class return TestResult that records the test results
  • Create a TestResult class to record test execution results
    • Make the run method of the TestCase class return the above
    • runCount
      • Number of executions
    • testStarted
      • Increment runCount at runtime
    • With the above, you can now count when success occurs, but you can also count when failure occurs.
      • I wanted to catch exceptions and record test failures, but I decided to shelve them for now.
      • "Small test"add

Chapter 22 Handling Failure

I will write the “smaller test” that was shelved in Chapter 21.

• "Even if the test fails, will the expected content be output properly?"confirm
• "For the result object, testStarted,testFailed on test failureI would like messages to be sent in order.”
• "If the results are output correctly, that means the messages were sent in the correct order."
  • What is the correct order?

• Small test -> testFailedResultFormatting method
• Return of big tests -> uncomment testFaildResult
• The mechanism you introduced during the small test?
  • I wonder if you mean the errorCount returned by the summary method...?
• Potential issue -> Errors in the setUp method are not caught

Chapter 23 Organize into suites

In Chapter 22, the output parts of the test results are duplicated, so remove the duplicates,Ability to run tests in bulkI'm going to make it.

• TestSuite class
• Use Composite pattern
  • “Individual elements and collections must respond to the same message.”
    • ="Methods with the same signature must be defined"
    • The Composite pattern hasCollecting Parameter patternare often used together
      • Pass the object for storing results
      • Often used when results are accumulated

• The instance creation part of TestResult was duplicated in TestCaseTest, so it was unified in the setUp method.

Chapter 24 Overall review of xUnit

We will review xUnit as a whole.

• hereTest cases are more important than implementation details
• It is important to implement xUnit yourself
  • Mastery: “Implementing it myself gives me the tools I know best.”
  • Exploration: If you try implementing xUnit when trying a new language, you will find that some of the functions necessary for programming have appeared.

• There is a difference between assertion failure and error.There is

Chapter 25. Patterns of Test-Driven Development

Let's move on to part 3. Part 3 is "TDD's 'best hit' pattern collection".

What is a test?

• Software testing writes automated tests
  • There is a difference between "tests that run automatically" and "press random buttons and look at the screen"
  • Negative loop: under stress less test execution -> more errors -> under stress less infinite loop
    • You can escape from the negative cycle by having tests run automatically.
    • Even when you're in a hurry,Automated testing gives you a chance to control your anxiety levelsThere is

independent testing

• Tests should not affect other tests
  • absolutely
  • Side benefits: Achieving a design with high cohesion and low coupling

TODO list

• When writing code, don't take a step until you know where you're going.
  • "When you have more things to do, it's easier to lose track of what you're doing."
  • When you come up with something new, all you have to do is add it to your ``I'll do it now'' or ``Later'' list, or decide if you don't need to do it.
• "The method of writing tests all at once did not work in two ways."
  • Tests that have already been written introduce some inertia when refactoring.
    • If you try to change it all at once, it will feel like a hassle.
  • If multiple tests are failing, you are far from the green bar
    • The basics that only one change can be made from the green bar
    • If the red bar stays for a long time, it becomes stressful.

test first

• When should you write tests?
  • Before writing the code to be tested
• Writing the test first can reduce stress.
  • Reverse stress diagram

assert first

• When should I write assertions?
  • write first
  • Where should I start building a system?
    • Starting from telling the story of what will happen after the system construction is completed.
  • Where should I start with features?
    • After writing the code, it will work like this, starting from writing the test.
  • The test is?
    • From writing the assertion that should pass at the end of the test
• Writing assert-first simplifies testing

test data

• Consider that there is a reader for the test.
• Use the same value only to represent one thing
• Use authentic data

explicit data

• Include expectations and results in the test itself so relationships are clearly visible
  • Write the expression inside the assertion
  • Magic numbers are sometimes acceptable if it makes it easier to understand.
    • Case by case

Chapter 26 Red Bar Pattern

“When and where to write a test and when to stop?”

• test showing one step
  • "When selecting the next test from the TODO list"
  • “Choose tests that you can learn something from and that give you confidence in your implementation.”
• first test
  • “Where should this feature belong?”
    • Authentic tests take too long to get feedback
    • Can you write a test-first implementation that requires a doctoral dissertation?
      • Choose a test that you can learn something from and that you can write quickly.
    • For well-understood implementations, write tests that require one or two features.
      • Because I already have confidence and a track record
• descriptive test
  • “Try to share your knowledge with others in the form of test code.”
• learning test
  • Writing tests for software you don't know well
    • The first time you use a new feature of the software
  • Instead of trying to use a method, write tests to make sure the API works as expected.
  • If the learning tests fail, the tests for our code should also fail.
    • If the learning test passes, the test for our code should also work.
• For derailments, go to TODO list
  • “The more you try to keep the conversation off-topic, the more it will become stuffy and the less good ideas will come out.”
  • But everyday programming is ordinary
  • The best path is not to get sidetracked
  • Don't let ideas interfere with your main work, put them on your TODO list
• regression test
  • (If you are a perfect programmer)Regression tests are tests that should have been written at the same time as the code was written.
  • If you need it later, the system will tell you that you haven't finished the design yet.
• break
  • Schedule regular hours, days, and weeks so you can take breaks.

• start over
  • When you get stuck, throw away the code and start again.
• cheap desk and good chair
  • buy a good chair
  • And the hardware too.

Chapter 27 Testing Patterns

• Divide overgrown tests that fail into smaller ones
• Mock Object pattern
  • Become mindful of object visibility
  • Leads to improved code visibility

• Self Shunt pattern
  • "When you want to test that objects interact properly with other objects"
  • The test case itself behaves like a mock object

• Log String pattern
  • When you want to test that methods are called in the correct order
  • Append to recording string every time method is called
  • Works well with the Self Shunt pattern
    • The test case class itself, which also serves as a Mock Object, can be implemented with Log functionality.
• Crash Test Dummy Pattern
  • Use when you want to test error handling parts that are difficult to occur.
  • Create a special object that raises an exception
    • By using anonymous inner classes, you can inherit a class that behaves as expected during testing and override it to throw an exception, without having to create a dummy class each time.
      • P.213
• Test that continues to fail
  • In personal development, when you stop writing code, it is easier to return to it if you leave a test that fails.
  • In team development, make sure the code passes the test and commit it.
    • Understanding check-in = commit
    • If an integration test fails, "throw away the work at hand and start over"

Chapter 28 Green Bar Pattern

• After tentative implementation, proceed to actual implementation
  • Effectiveness of temporary implementation
    • Psychological effect: I feel safe when the bar is green.
    • Scope control: Don't get distracted by irrelevant issues
  • Isn't a temporary implementation contrary to the statement that "unnecessary code should not be written"?
    • It will be removed during the refactoring process.
• triangulation
  • How to carefully generalize from a tentative implementation state
  • "Temporary implementation drives development by intentionally causing duplication of test code and product code."
  • "The rules for single-report triangulation are simple, but it can lead to an infinite loop."
• obvious implementation
  • Only obvious implementation “forces you to be perfect”
  • When things don't go well, the need to gear down by using temporary implementation and triangulation.
• from one to many
  • When implementing operations that handle collections, start with one element and change it to multiple elements.

Chapter 29. xUnit Patterns

• assertion
  • Judgments are made based on truth values
  • The truth value is investigated by the computer (assert function)
• You should write tests only with public behavior.
• Fixture
  • setUp method can be used
    • Advantage: Common processing before test execution can be grouped together
    • Disadvantages: Must remember the contents of setUp when reading the test code

• external fixture
  • Use tearDown when releasing external resources created as fixtures
• test method
  • Fixture: Class
  • Test: Method
  • Test method aims for 3 lines
  • It's easier to understand if you create an outline
    • Comments like /* Add to double space */
• Testing for exceptions
  • A test that expects an exception to occur is
    • Catch and squish the expected exception
    • Write the test so that it fails only when the expected exception does not occur
      • fail() method
    • "Be very careful to catch only expected exceptions."
• Test all at once
  • Adding tests using the collection parameter pattern

Chapter 30 Design Patterns

• ``No matter how diverse the problems themselves are and how different their backgrounds may be, they are actually general, and we can expect that their sub-levels are also general.''
  • "Command: Expressing different execution of processing with objects rather than just messages"
  • ``Value Object'': Create an object whose value never changes once it is created, preventing alias reference problems.''
  • "Null Object: Expressing special situations with objects"
  • "Template Method: The order of processing is expressed as a sequence of abstract methods, and individual processing is realized through inheritance."
  • "Pluggable Object: Express variations by calling objects with two or more implementations"
  • "Factory Method: Create objects by calling methods instead of constructors"
  • “Imposter: Create variations by creating new implementations of existing protocols”
  • "Composite: Expressing a combination of behaviors of objects as one object"
  • "Collection Paramater: Pass an object as an argument to collect processing results from various objects"

Chapter 31. Refactoring

• eliminate differences
  • To standardize similar code, gradually bring the contents closer together, and when they match completely, combine them.
  • You can share similar things such as loop structures, conditional branch contents, methods, classes, etc.
• Separation of changes. The following may be available
  • Extracting objects
  • method object
• Data structure changes
  • You can change either the old or new flow, or the new old flow.

• Method extraction
  • For complicated and long methods, separate parts into separate methods and call that method.
  • Be careful not to overdo it
  • If you get stuck, try returning the extracted method to the original method using "method inlining"
• Inlining methods
  • It seems different from simple inlining, and this part is also a little difficult...

• Extracting an interface
  • Be careful when naming
    • IFile(Interface)->File is ✕
    • File (interface)->DiskFile is ○
• Move method
  • If two or more message calls are being made to one object, consider moving the method to the target object.
  • “The results are often spectacular.”
• method object
  • "Express complex methods that require multiple parameters or local variables"
  • "Useful in the preparation stage of introducing new logic to the system"
• Add parameters
  • "First, add a new parameter, delete any uses of the old parameter, and finally delete the old parameter."
• Moving parameters from method to constructor
  • ``If you are passing the same parameter to multiple methods of an object, you can eliminate duplication by passing the parameter only once in advance.''

Chapter 32 Learn TDD

• How big is a step?
  • You should be able to do both small and large things.
  • "When refactoring, try to break the steps into many smaller steps."
  • "Automatic refactoring capabilities dramatically accelerate development"
• Is there anything I don't need to test?
  • "Write tests until anxiety turns to boredom"
  • If you want to give an answer, what should you test?
    • conditional branch
    • loop
    • operation
    • polymorphism
    • Of the above, only those written by yourself
• Can you identify a good test?
  • Testing can detect and tell you about design flaws.
    • "The cord required for preparation is long"
      • If the preparation takes more than 100 lines, the object is too large and it is better to split it up.
    • "Duplicate preparatory code"
      • If you can't easily find a place to put common prep code, you have too many objects that are closely related to each other.
    • "Test execution time is long"
      • I want it within 10 minutes
      • Because it runs less frequently
    • brittle test
      • If a test fails unexpectedly, there is a possibility that something in the application is affecting each other in an unexpected way.
        • break or integrate two parts
• How TDD guides frameworks
  • "Write code for tomorrow, design for today"
  • The open-closed principle is satisfied by the occurrence of variations.
    • "Objects should be open to use and closed to modification"
  • "Ultimately, the sooner variations are introduced, the more TDD becomes indistinguishable from up-front design."

• How much feedback do you need?
  • =How many tests do you need?
    • Think of MTBF (Mean Time Between Failures)
    • It seems better not to write tests that are unlikely to occur during the moving period.
      • If you are developing a pacemaker and the MTBF is 10 to 100 years, it makes sense to conduct tests under extremely detailed and impossible conditions.
• When should you delete a test?
  • When there is overlap between tests, should both be kept?
    • Criterion 1: Confidence
      • If removing the test will make you less confident in your behavior, don't remove it.
    • Criterion 2: Communication
      • Even if the test executes the same part of the code, don't delete it if it looks like a different scenario to the reader.
    • If there is overlap in either aspect, delete the one that is not useful.
• Do programming languages and environments affect TDD?
  • If you have an environment where it is easy to run the TDD cycle, you will want to try various things, which will increase development efficiency.
    • Certainly, if it is an IDE that is designed for automatic testing, you will want to run the test.
• Can you test drive a huge system?
  • "The total amount of functionality appeared to be unrelated to the effectiveness of TDD."
    • 250,000 lines of test code
    • 4,000 test cases
    • Pass within 20 minutes
    • All were executed several times a day.
• Can application-level testing drive development?
  • If you drive development with small tests, there is a risk that what the customer wanted and what you ended up with were completely different.
  • Solution: Have customers write application-level tests
    • It can be difficult for the following reasons
      • Cooperation among team members is required
      • Customers are now responsible for writing tests.
    • The TDD in this book is a technique that can be done by yourself.
• How can I switch to TDD midway?
  • "The biggest problem is that code that is written without thinking about testing is often difficult to test."
  • There are no automated tests to rewrite the code, so refactoring is bound to fail.
  • Writing tests for everything and refactoring the entire system is a bad idea.
    • "It takes several months even though there are no new features."
  • Remedy: Narrow the scope of your changes
    • If you know it can be easily changed, but don't plan on changing it, leave it as is.
    • Eliminate deadlock between testing and refactoring
      • Get feedback through means other than testing
        • For example, work carefully in pairs.
        • Over time, frequently changing parts start to look like they are developed in a test-driven manner.
• Who is TDD for?
  • Those with souls who seek solace in elegance
  • Geeks with a deep passion for code
  • Engineering accounts for 20% in success
    • Even ordinary engineering can lead to success if the remaining 80% is solid.
    • From this perspective, TDD is “too much”
  • ``TDD is based on the naive and strange premise that ``If you write better code, it will work better''.''
• Does TDD depend on the initial state?
  • unaffected (or so it seems)
  • Chottoyokwakaranai
• Relationship between TDD and patterns
  • If you follow the pattern, it will take time to investigate at first, but it will become faster later.
  • TDD can be used as an implementation method for pattern-driven design
• Why does TDD work?
  • Because TDD reduces defects
    • There is no scientific basis by the author.
    • There is anecdotal evidence
    • (Also, I feel like there is evidence in the form of data recently)
• The origin of the name
  • "TDD is an analysis technique, a design technique, and in fact a technique for structuring all development activities."
• Relationship between TDD and XP practices
  • You can still get XP with TDD.
• Darach's challenge
  • Darach Ennis says he is trying to expand the scope of application of TDD. for example
    • GUI can also be tested
    • Can automatically test distributed systems
    • You can write database schema tests first.
    • Also test code that is automatically generated by third-party code or tools
    • Test-first to develop compilers and interpreters for programming languages to a level where you can use them.