Tdd

" The vocabulary for talking about this soon gets messy - all sorts of words are used: stub, mock, fake, dummy. " Test Double the generic term for any kind of pretend object used in place of a real object for testing purposes. five particular kinds of double (1) Dummy objects passed around but never actually used. eg. fill parameter lists (2) Fake objects working implementations shortcut which makes them not suitable for production eg....

I have found multiple ways of looking at this: behaviour vs methods behaviour vs state behaviour vs implementation (1) Unit-Test Behaviour, Not Methods focus on the features that the object under test should provide, We need to know how to use the class to achieve a goal, not how to exercise all the paths through its code. Describing Behavior, Not API Features We need to know how to use the class to achieve a goal, not how to exercise all the paths through its code....

Caveat: test terminology is not very standardized End to end tests Focused on business requirements. Exercise the complete flow, including external systems. Usually these tests are slow to execute. Acceptance tests Focused on business requirements. Exercise all parts of the flow in our system. Compromise on feedback and speed of execution. Faster than end to end tests, but not as thorough. Integration tests Focused on technical implementation. Exercise parts of our system that connect with external systems....

Pattern: Include the deployment step in the testing process We want our test to - start from scratch, - build a deployable system, - deploy it into a production-like environment, and then - run the tests through the deployed system benefits deployment is error prone => now covered by tests development team bumps into the rest of the organization If it’s going to take six weeks and four signatures to set up a database, we want to know now, not two weeks before delivery....

Roles, Responsibilities, Collaborators An object is an implementation of one or more roles; a role is a set of relatedresponsibilities; and a responsibility is an obligation to perform a task or know information. A collaboration is an interaction of objects or roles (or both). (origin: Wirfs-Brock and McKean in [Wirfs-Brock03]) (src: Book_ Growing Object Oriented Software, Guided By Tests - Steve Freeman & Nat Pryce)

start each feature with an acceptance test Domain Language only write the acceptance test using only terminology from the application’s domain, not from the underlying technologies (such as databases or web servers) benefits: prevent assumptions about implementation clarity focus on limited set of features user’s point of view (src: Book_ Growing Object Oriented Software, Guided By Tests - Steve Freeman & Nat Pryce) In Book_ Agile Technical Practices Distilled - Pedro, Marco, Alessandro they define test boundaries of acceptance test without external dependencies....

Quote: Walking skeleton definition A “walking skeleton” is an implementation of the thinnest possible slice of real functionality that we can automatically build, deploy, and test end-to-end. -- Alistair Cockburn (src: Book_ Growing Object Oriented Software, Guided By Tests - Steve Freeman & Nat Pryce) (origin: [Cockburn04]) keep the skeleton’s application functionality so simple that it’s obvious and uninteresting For example, for a database-backed web application, a skeleton would show a flat web page with fields from the database....

Tidy First? - Kent Beck (https://www.youtube.com/watch?v=BFFY9Zor6zw) 2 types of people: waiters and changers 2 relationships: - waiter - changer - changer - changer (breaking api changes) -– 4 levels of insight into design there’s changes there’s 2 types of changes: structure & behavior there’s a sequence, which you can plan (“I can change this structure, so I can do that behavior change easier”) experiment: make pull requests with only behavior or only structure, get into prod user visible changes at the end of the sequence...

Chapter: TDD The Three Laws of TDD You are not allowed to write any production code until you have first written a failing unit test. You are not allowed to write more of a unit test than is sufficient to fail—and not compiling is failing. You are not allowed to write more production code that is sufficient to pass the currently failing unit test.

Article_ TDD is dead. Long live testing. - David Heinemeier Hansson Paper_ Why Most Unit Testing is Waste - James O Coplien [Notes] Video: Writing Software - David… [Notes] Video: Writing Software - David Heinemeier Hansson computer science vs building information systems pseudo-sciences eg. diet books -> programmers feeds Imposter Syndrome === TDD = most successful software diet - test first - test driven design measure of success = easy to test?...