SlideShare uma empresa Scribd logo
1 de 34
Baixar para ler offline
Misconceptions
of Unit Testing

for Scrum Gathering Shanghai 2011



by Terry.YinZhe@gmail.com

      twitter: @terryyin
      Sina 微博:@terry尹哲
Question: Which is likely to be the logo for unit testing?
Myth 1: Why UT?

Unit Testing Is About Finding Bugs
● People are told that UT can help them find a lot of bugs
   ○ This is a common reason why people stop doing UT after a few
     months.
   ○ And this is why management stop believe in UT too.

● Build and fix vs. Prevent from having bugs
Then, why do we do UT?


                    Unit Test
Tips
 ● You don't want the team to generate buggy code in
   the first place.
 ● You want the code to be protected for
   implementing your future ideas, and still keep
   productive in the future.
 ● Tell your team that they will sleep better when they
   know that their source code are protected by UT.
Myth 2: What to Test?

UT tests the user requirement
● Most people (including and especially PO) care more about
   ○ Is my software functioning as per the requirement?

● But in the same time, they could omit
   ○ Does my software have a good internal design?
Internal Quality vs. External Quality




Unfortunately, internal quality is very often not directly linked with current
external quality.
UT is more about internal quality than external quality.
Tips
● The main purpose of UT is not to cover your
  system requirement
● The internal quality is as important as external
  quality
   ○ Good design (testable design)
UT is duplication

 ● Well, yes.
 ● As the RAID system in computer system, double entry book
   keeping in accounting, extra protections in rock climbing, UT
   is a necessary redundancy in programming.
Myth 3: Where to put the
        focus?
Let's add UT, but don't touch the code
you want your good things in your
product, not somewhere else.

Not even in the tests.
Tips
● Don't force your team to test badly designed
  code
    ○ Ask them to make it testable first.
● "Complex" test framework and tests do not
  always mean good thing.
    ○ You want great product, not great UT
    ○ Nor great document
Myth 4: How to Test?

  UT cases are fragile when I do an architectural change.

Comprehensive System (or functional) Regression test can
                    replace UT
Big, end to end test


      Oh, shoot! I
      climbed the
      wrong rock.
you can't be more stable than
your dependencies
So, it's time to break the dependencies.
Example
Good unit test has very limited scope
Tips
● Testability is the key
● Challenge your team to have SOLID design
● Don't always have all dependent tests
Myth 5: Who Test?


By different person/team
    Is a separate task
● Because they are more likely to break the software?
   ○ That's simply a waste of time

● If they made a wrong design, they can not find it through
 UT
    ○ Yes, that is simply true.
Test Example
test_is_able_to_chow([2, 3], 1);
test_is_able_to_chow([2, 3], 4);
test_is_able_to_chow([1, 3], 2);
test_is_not_able_to_chow([1, 4], 2);
test_is_able_to_chow([1, 2, 3], 2);
test_is_not_able_to_chow([1], 2);



                                       This is not a test problem,
                                       it's a design problem.
Tips
● Just let people who do the design to write the
  protection of their design
● UT should be a natural part of coding
● Nothing can replace domain knowledge or 10-
  year experience
   ○ No silver bullet.
Myth 6: When?

              Let's add UT later
writing code with unit tests takes much more time
Well, talk to him about your idea.
● Michael Feathers' definition for legacy code.
● If you find yourself in a hole, what is the first thing to do?



● Test later = test never
Debug vs. Precise/immediate Failure Report


                   These cases, they are more
                   meaningful when they pass.




                           These cases, they can tell
                           us a lot of useful
                           information when they fail.
8 shames, 8 honors
以动手实践为荣,以只看不练为耻。 
以打印日志为荣,以单步跟踪为耻。
以空白分隔为荣,以制表分隔为耻。 
以单元测试为荣,以手工测试为耻。 

以代码重用为荣,以复制粘贴为耻。 
以多态应用为荣,以分支判断为耻。 
以短小精悍为荣,以冗余拖沓为耻。 
以总结思考为荣,以不求甚解为耻。

      Honor for get your hands dirty, shame for just watching.
      Honor for logging, shame for debugging.
      Honor for indenting with spaces, shame for using tabs.
      Honor for unit testing, shame for manual testing.

      Honor for code reusing, shame for copy-paste.
      Honor for polymorphism, shame for using ifs.
      Honor for short and neat, shame for tediousness.
      Honor for summarizing and thinking, shame for superficial understanding.
Tips
● 'time to find the bug' and 'time to locate the bug'
  are the keys to productivity.
● Any other task will look 'more important' to you
  than adding UT in the future.
● It is suppose to be faster to do the UT while
  coding.
     ○ Are you making the problem better or
       worse?
It's software design, after all.
Thanks to

Gerard Meszaros
for reviewing my slides during Scrum Gathering Shanghai
2011.

Mais conteúdo relacionado

Mais procurados

The pragmatic programmer
The pragmatic programmerThe pragmatic programmer
The pragmatic programmerJoel Corrêa
 
Are Automated Debugging Techniques Actually Helping Programmers
Are Automated Debugging Techniques Actually Helping ProgrammersAre Automated Debugging Techniques Actually Helping Programmers
Are Automated Debugging Techniques Actually Helping ProgrammersChris Parnin
 
Pragmatic Programmer
Pragmatic ProgrammerPragmatic Programmer
Pragmatic ProgrammerBert Añasco
 
Programming the Programmer
Programming the ProgrammerProgramming the Programmer
Programming the Programmervipinkumar_n
 
The Art of Questioning to improve Software Testing, Agile and Automating
The Art of Questioning to improve Software Testing, Agile and AutomatingThe Art of Questioning to improve Software Testing, Agile and Automating
The Art of Questioning to improve Software Testing, Agile and AutomatingAlan Richardson
 
Fast ways to create better products - by UX Rocks
Fast ways to create better products - by UX RocksFast ways to create better products - by UX Rocks
Fast ways to create better products - by UX RocksUX Rocks
 
Exploratory Testing with the Team_ATDNL
Exploratory Testing with the Team_ATDNLExploratory Testing with the Team_ATDNL
Exploratory Testing with the Team_ATDNLMaaike Brinkhof
 
Go/Ruby/Java: What's next?
Go/Ruby/Java: What's next?Go/Ruby/Java: What's next?
Go/Ruby/Java: What's next?Hernan Wilkinson
 
Fast ways to create better products
Fast ways to create better products Fast ways to create better products
Fast ways to create better products Oana Blaga
 
Paradigm Shifts are Never Pretty
Paradigm Shifts are Never PrettyParadigm Shifts are Never Pretty
Paradigm Shifts are Never PrettySarah O'Keefe
 
Agile2012 klingon
Agile2012 klingonAgile2012 klingon
Agile2012 klingondrewz lin
 
What Hollywood Can Teach Us about Software Testing
What Hollywood Can Teach Us about Software TestingWhat Hollywood Can Teach Us about Software Testing
What Hollywood Can Teach Us about Software TestingTechWell
 
Summerschool P4, Prototyping
Summerschool P4, PrototypingSummerschool P4, Prototyping
Summerschool P4, PrototypingLouis Klomp
 
4YFN 2016 Guerrilla UX
4YFN 2016 Guerrilla UX4YFN 2016 Guerrilla UX
4YFN 2016 Guerrilla UXSarah Rink
 

Mais procurados (20)

The pragmatic programmer
The pragmatic programmerThe pragmatic programmer
The pragmatic programmer
 
Are Automated Debugging Techniques Actually Helping Programmers
Are Automated Debugging Techniques Actually Helping ProgrammersAre Automated Debugging Techniques Actually Helping Programmers
Are Automated Debugging Techniques Actually Helping Programmers
 
Pragmatic Programmer
Pragmatic ProgrammerPragmatic Programmer
Pragmatic Programmer
 
Programming the Programmer
Programming the ProgrammerProgramming the Programmer
Programming the Programmer
 
The Art of Questioning to improve Software Testing, Agile and Automating
The Art of Questioning to improve Software Testing, Agile and AutomatingThe Art of Questioning to improve Software Testing, Agile and Automating
The Art of Questioning to improve Software Testing, Agile and Automating
 
Agile Testing: Whole Team Approach
Agile Testing: Whole Team ApproachAgile Testing: Whole Team Approach
Agile Testing: Whole Team Approach
 
Fast ways to create better products - by UX Rocks
Fast ways to create better products - by UX RocksFast ways to create better products - by UX Rocks
Fast ways to create better products - by UX Rocks
 
Exploratory Testing with the Team_ATDNL
Exploratory Testing with the Team_ATDNLExploratory Testing with the Team_ATDNL
Exploratory Testing with the Team_ATDNL
 
Unit testing-patterns
Unit testing-patternsUnit testing-patterns
Unit testing-patterns
 
Go/Ruby/Java: What's next?
Go/Ruby/Java: What's next?Go/Ruby/Java: What's next?
Go/Ruby/Java: What's next?
 
TDD & Refactoring
TDD & RefactoringTDD & Refactoring
TDD & Refactoring
 
Fast ways to create better products
Fast ways to create better products Fast ways to create better products
Fast ways to create better products
 
Code reviews
Code reviewsCode reviews
Code reviews
 
Paradigm Shifts are Never Pretty
Paradigm Shifts are Never PrettyParadigm Shifts are Never Pretty
Paradigm Shifts are Never Pretty
 
Agile2012 klingon
Agile2012 klingonAgile2012 klingon
Agile2012 klingon
 
5 why analysis
5 why analysis5 why analysis
5 why analysis
 
What Hollywood Can Teach Us about Software Testing
What Hollywood Can Teach Us about Software TestingWhat Hollywood Can Teach Us about Software Testing
What Hollywood Can Teach Us about Software Testing
 
Summerschool P4, Prototyping
Summerschool P4, PrototypingSummerschool P4, Prototyping
Summerschool P4, Prototyping
 
4YFN 2016 Guerrilla UX
4YFN 2016 Guerrilla UX4YFN 2016 Guerrilla UX
4YFN 2016 Guerrilla UX
 
9akk105151d0113 5 whys
9akk105151d0113 5 whys9akk105151d0113 5 whys
9akk105151d0113 5 whys
 

Semelhante a Misconceptions Of Unit Testing

Effective Unit Testing
Effective Unit TestingEffective Unit Testing
Effective Unit TestingEyal Kenig
 
Writing Tests Effectively
Writing Tests EffectivelyWriting Tests Effectively
Writing Tests EffectivelyPaul Boocock
 
TDD and Simple Design Workshop - Session 1 - March 2019
TDD and Simple Design Workshop - Session 1 - March 2019TDD and Simple Design Workshop - Session 1 - March 2019
TDD and Simple Design Workshop - Session 1 - March 2019Paulo Clavijo
 
How to be a 10x Engineer
How to be a 10x EngineerHow to be a 10x Engineer
How to be a 10x EngineerNick Sullivan
 
Software Development Essential Skills
Software Development Essential SkillsSoftware Development Essential Skills
Software Development Essential SkillsJohn Choi
 
How to deliver the right software (Specification by example)
How to deliver the right software (Specification by example)How to deliver the right software (Specification by example)
How to deliver the right software (Specification by example)Asier Barrenetxea
 
Picking the right architecture and sticking to it
Picking the right architecture and sticking to itPicking the right architecture and sticking to it
Picking the right architecture and sticking to itPetter Holmström
 
Unit Testing and TDD 2017
Unit Testing and TDD 2017Unit Testing and TDD 2017
Unit Testing and TDD 2017Xavi Hidalgo
 
How Indeed asks coding interview questions
How Indeed asks coding interview questionsHow Indeed asks coding interview questions
How Indeed asks coding interview questionsFangda Wang
 
TDD - Christchurch APN May 2012
TDD - Christchurch APN May 2012TDD - Christchurch APN May 2012
TDD - Christchurch APN May 2012Alan Christensen
 
30% faster coder on-boarding when you have a code cookbook
30% faster coder on-boarding when you have a code cookbook30% faster coder on-boarding when you have a code cookbook
30% faster coder on-boarding when you have a code cookbookGabriel Paunescu 🤖
 
Pairing w developers_stpconpics
Pairing w developers_stpconpicsPairing w developers_stpconpics
Pairing w developers_stpconpicsLanette Creamer
 
Black Ops Testing Workshop from Agile Testing Days 2014
Black Ops Testing Workshop from Agile Testing Days 2014Black Ops Testing Workshop from Agile Testing Days 2014
Black Ops Testing Workshop from Agile Testing Days 2014Alan Richardson
 
Pair Programming in Theory and Practice By Garrick West
Pair Programming in Theory and Practice By Garrick WestPair Programming in Theory and Practice By Garrick West
Pair Programming in Theory and Practice By Garrick WestXP Conference India
 
From Gatekeeper to Partner by Kelsey Shannahan
From Gatekeeper to Partner by Kelsey ShannahanFrom Gatekeeper to Partner by Kelsey Shannahan
From Gatekeeper to Partner by Kelsey ShannahanQA or the Highway
 
Test-Driven Development
 Test-Driven Development  Test-Driven Development
Test-Driven Development Amir Assad
 

Semelhante a Misconceptions Of Unit Testing (20)

Effective Unit Testing
Effective Unit TestingEffective Unit Testing
Effective Unit Testing
 
Writing Tests Effectively
Writing Tests EffectivelyWriting Tests Effectively
Writing Tests Effectively
 
TDD and Simple Design Workshop - Session 1 - March 2019
TDD and Simple Design Workshop - Session 1 - March 2019TDD and Simple Design Workshop - Session 1 - March 2019
TDD and Simple Design Workshop - Session 1 - March 2019
 
Design Sprints
Design SprintsDesign Sprints
Design Sprints
 
Best pratice
Best praticeBest pratice
Best pratice
 
How to be a 10x Engineer
How to be a 10x EngineerHow to be a 10x Engineer
How to be a 10x Engineer
 
Software Development Essential Skills
Software Development Essential SkillsSoftware Development Essential Skills
Software Development Essential Skills
 
How to deliver the right software (Specification by example)
How to deliver the right software (Specification by example)How to deliver the right software (Specification by example)
How to deliver the right software (Specification by example)
 
Picking the right architecture and sticking to it
Picking the right architecture and sticking to itPicking the right architecture and sticking to it
Picking the right architecture and sticking to it
 
Unit Testing and TDD 2017
Unit Testing and TDD 2017Unit Testing and TDD 2017
Unit Testing and TDD 2017
 
How Indeed asks coding interview questions
How Indeed asks coding interview questionsHow Indeed asks coding interview questions
How Indeed asks coding interview questions
 
Agile Practices
Agile PracticesAgile Practices
Agile Practices
 
TDD - Christchurch APN May 2012
TDD - Christchurch APN May 2012TDD - Christchurch APN May 2012
TDD - Christchurch APN May 2012
 
30% faster coder on-boarding when you have a code cookbook
30% faster coder on-boarding when you have a code cookbook30% faster coder on-boarding when you have a code cookbook
30% faster coder on-boarding when you have a code cookbook
 
Pairing w developers_stpconpics
Pairing w developers_stpconpicsPairing w developers_stpconpics
Pairing w developers_stpconpics
 
Black Ops Testing Workshop from Agile Testing Days 2014
Black Ops Testing Workshop from Agile Testing Days 2014Black Ops Testing Workshop from Agile Testing Days 2014
Black Ops Testing Workshop from Agile Testing Days 2014
 
Pair Programming in Theory and Practice By Garrick West
Pair Programming in Theory and Practice By Garrick WestPair Programming in Theory and Practice By Garrick West
Pair Programming in Theory and Practice By Garrick West
 
From Gatekeeper to Partner by Kelsey Shannahan
From Gatekeeper to Partner by Kelsey ShannahanFrom Gatekeeper to Partner by Kelsey Shannahan
From Gatekeeper to Partner by Kelsey Shannahan
 
Test-Driven Development
 Test-Driven Development  Test-Driven Development
Test-Driven Development
 
Intro to TDD
Intro to TDDIntro to TDD
Intro to TDD
 

Mais de Terry Yin

Test Driven Development of A Static Code Analyzer
Test Driven Development of A Static Code AnalyzerTest Driven Development of A Static Code Analyzer
Test Driven Development of A Static Code AnalyzerTerry Yin
 
Six Years of Teaching Certified Scrum Developers
Six Years of Teaching Certified Scrum DevelopersSix Years of Teaching Certified Scrum Developers
Six Years of Teaching Certified Scrum DevelopersTerry Yin
 
Abstraction is a communication tool
Abstraction is a communication toolAbstraction is a communication tool
Abstraction is a communication toolTerry Yin
 
No Reuse Before Use
No Reuse Before UseNo Reuse Before Use
No Reuse Before UseTerry Yin
 
Programming exercises
Programming exercisesProgramming exercises
Programming exercisesTerry Yin
 
Adding Unit Test To Legacy Code
Adding Unit Test To Legacy CodeAdding Unit Test To Legacy Code
Adding Unit Test To Legacy CodeTerry Yin
 

Mais de Terry Yin (6)

Test Driven Development of A Static Code Analyzer
Test Driven Development of A Static Code AnalyzerTest Driven Development of A Static Code Analyzer
Test Driven Development of A Static Code Analyzer
 
Six Years of Teaching Certified Scrum Developers
Six Years of Teaching Certified Scrum DevelopersSix Years of Teaching Certified Scrum Developers
Six Years of Teaching Certified Scrum Developers
 
Abstraction is a communication tool
Abstraction is a communication toolAbstraction is a communication tool
Abstraction is a communication tool
 
No Reuse Before Use
No Reuse Before UseNo Reuse Before Use
No Reuse Before Use
 
Programming exercises
Programming exercisesProgramming exercises
Programming exercises
 
Adding Unit Test To Legacy Code
Adding Unit Test To Legacy CodeAdding Unit Test To Legacy Code
Adding Unit Test To Legacy Code
 

Misconceptions Of Unit Testing

  • 1. Misconceptions of Unit Testing for Scrum Gathering Shanghai 2011 by Terry.YinZhe@gmail.com twitter: @terryyin Sina 微博:@terry尹哲
  • 2. Question: Which is likely to be the logo for unit testing?
  • 3. Myth 1: Why UT? Unit Testing Is About Finding Bugs
  • 4. ● People are told that UT can help them find a lot of bugs ○ This is a common reason why people stop doing UT after a few months. ○ And this is why management stop believe in UT too. ● Build and fix vs. Prevent from having bugs
  • 5. Then, why do we do UT? Unit Test
  • 6. Tips ● You don't want the team to generate buggy code in the first place. ● You want the code to be protected for implementing your future ideas, and still keep productive in the future. ● Tell your team that they will sleep better when they know that their source code are protected by UT.
  • 7. Myth 2: What to Test? UT tests the user requirement
  • 8. ● Most people (including and especially PO) care more about ○ Is my software functioning as per the requirement? ● But in the same time, they could omit ○ Does my software have a good internal design?
  • 9. Internal Quality vs. External Quality Unfortunately, internal quality is very often not directly linked with current external quality.
  • 10. UT is more about internal quality than external quality.
  • 11. Tips ● The main purpose of UT is not to cover your system requirement ● The internal quality is as important as external quality ○ Good design (testable design)
  • 12. UT is duplication ● Well, yes. ● As the RAID system in computer system, double entry book keeping in accounting, extra protections in rock climbing, UT is a necessary redundancy in programming.
  • 13. Myth 3: Where to put the focus? Let's add UT, but don't touch the code
  • 14. you want your good things in your product, not somewhere else. Not even in the tests.
  • 15. Tips ● Don't force your team to test badly designed code ○ Ask them to make it testable first. ● "Complex" test framework and tests do not always mean good thing. ○ You want great product, not great UT ○ Nor great document
  • 16. Myth 4: How to Test? UT cases are fragile when I do an architectural change. Comprehensive System (or functional) Regression test can replace UT
  • 17. Big, end to end test Oh, shoot! I climbed the wrong rock.
  • 18. you can't be more stable than your dependencies
  • 19. So, it's time to break the dependencies.
  • 21. Good unit test has very limited scope
  • 22. Tips ● Testability is the key ● Challenge your team to have SOLID design ● Don't always have all dependent tests
  • 23. Myth 5: Who Test? By different person/team Is a separate task
  • 24. ● Because they are more likely to break the software? ○ That's simply a waste of time ● If they made a wrong design, they can not find it through UT ○ Yes, that is simply true.
  • 25. Test Example test_is_able_to_chow([2, 3], 1); test_is_able_to_chow([2, 3], 4); test_is_able_to_chow([1, 3], 2); test_is_not_able_to_chow([1, 4], 2); test_is_able_to_chow([1, 2, 3], 2); test_is_not_able_to_chow([1], 2); This is not a test problem, it's a design problem.
  • 26. Tips ● Just let people who do the design to write the protection of their design ● UT should be a natural part of coding ● Nothing can replace domain knowledge or 10- year experience ○ No silver bullet.
  • 27. Myth 6: When? Let's add UT later writing code with unit tests takes much more time
  • 28. Well, talk to him about your idea.
  • 29. ● Michael Feathers' definition for legacy code. ● If you find yourself in a hole, what is the first thing to do? ● Test later = test never
  • 30. Debug vs. Precise/immediate Failure Report These cases, they are more meaningful when they pass. These cases, they can tell us a lot of useful information when they fail.
  • 31. 8 shames, 8 honors 以动手实践为荣,以只看不练为耻。  以打印日志为荣,以单步跟踪为耻。 以空白分隔为荣,以制表分隔为耻。  以单元测试为荣,以手工测试为耻。  以代码重用为荣,以复制粘贴为耻。  以多态应用为荣,以分支判断为耻。  以短小精悍为荣,以冗余拖沓为耻。  以总结思考为荣,以不求甚解为耻。 Honor for get your hands dirty, shame for just watching. Honor for logging, shame for debugging. Honor for indenting with spaces, shame for using tabs. Honor for unit testing, shame for manual testing. Honor for code reusing, shame for copy-paste. Honor for polymorphism, shame for using ifs. Honor for short and neat, shame for tediousness. Honor for summarizing and thinking, shame for superficial understanding.
  • 32. Tips ● 'time to find the bug' and 'time to locate the bug' are the keys to productivity. ● Any other task will look 'more important' to you than adding UT in the future. ● It is suppose to be faster to do the UT while coding. ○ Are you making the problem better or worse?
  • 33. It's software design, after all.
  • 34. Thanks to Gerard Meszaros for reviewing my slides during Scrum Gathering Shanghai 2011.