tools! Unconsciously incompetent and life is good. The maintenance team will handle it. FML - This is getting complicated. This app was supposed to be small. It was a one off! Did you know that 5 “Marlboro Men” died of smoking-related diseases? #notsustainable EEEEEEEEEEEEE @#$&!?
mistakes. End-to-end tests are costly and brittle and sometimes impossible. Isolation yields more pointed feedback. Developers test too! What’s 10% mean? 90%? Count? Runtime? How big a pyramid are we talking? Uh… I’m a test automation person… what does this mean for me? Where do all of these unit tests come from? EEEEEEEEEEEEE
feel.” Our organization/culture has a huge influence on our testing strategy. Helps explain the “testing pyramid” model. Always nice to present a counter- example. “This describes us. THIS DESCRIBES US. Changing this threatens my role.” “We have a major investment in Test Center.” “Why do we keep ignoring those 500 cucumber test failures?” Cupcakes are delicious. I prefer mine kitten-free. EEEEEEEEEEEEE
different concerns. Maybe we shouldn’t invent and/or automate everything ourselves (performance testing, etc.)? Manual testing ain’t dead. I don’t get the “support the team” vs. “critique the product” divide. Business-technology is kind of a limiting divide, don’t you think? How do tests tell us if we’re building something people want / will use? EEEEEEEEEEEEE
Guided By Tests” •Tests as a design tool (interface discovery). •Heavy use of Mock Objects (a stub with an assert). •White Box: discover interfaces and interactions. •Tests are a industrial by-product of design. •AKA - “Mockist” (Fowler) “LONDON SCHOOL” TDD
Library Write an integrated test after Application Service Mock / Stub Adapter Mock / Stub Business Object / Entity Actual Application Service Controller
ensure unit tests get written and not forgotten / put off. Design your code by treating everything as an API. Your tests are simply the first client! Scales with level of detail: product, iteration, code artifact. A nice tool, but you know what they say about silver bullets. Discipline is hard. I forget to refactor sometimes. Rugged and steep learning curve. Mock objects are weird. London school tests seem redundant (and weird), especially so with code first. Practicing both Detroit and London (state- vs. interaction- based verification) blurs the line of unit. EEEEEEEEEEEEE
a huge difference in product and code quality. “The secret of genius is to carry the spirit of the child into old age, which means never losing your enthusiasm.” - Huxley Is execution bias creating a team fixation? What other things could we do to improve our product and/or code quality? “Enthusiasm just creates bubbles; it doesn't keep them from popping.” - Svitak EEEEEEEEEEEEE
testing (for the people creating the tests). A coverage tool can help fortify refactoring resolve and be a useful, if not temporary, tool on the team- wide test-driven path. Manager: “How else do you expect me to measure quality! If I can’t measure it, I can’t manage it.” Developer to Manager: “Do we get to measure you by useless minutes spent in meetings?” Coverage tells me nothing about test suite quality. Maybe start with an engaged senior engineer? EEEEEEEEEEEEE
create” - Carnegie It’s an all hands on deck approach. A sound alternative to maintaining extensive DB of manual test scripts (which often go stale). Developers develop. Testers test. Stay off our lawns. What about my test scripts?! As a manager of testers, engineers, or product(s) - how do I know we haven’t regressed? EEEEEEEEEEEEE
FEEDBACK. Heavy use of test doubles (mocks, stubs) to design object interactions. Helps us discover boundaries. White-box. That’s OK! “London School.” New-old school. Deletion is OK! It’s scaffolding!