• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

How does one defend Pragmatic Unit Testing over through Unit testing?

 
Ranch Hand
Posts: 35
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
How does one defend "Pragmatic Unit Testing" over "Through Unit Testing" To me it seems like the assumption that a developer can guess what needs to be tested puts a lot of faith on a human. If I, as a developer, was so good at writing code that I knew what needed testing, it implies why bother testing at all? I know, as a developer, where my errors will occur in the first place, just don't make the errors in the first place.
 
author
Posts: 799
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Paul,

Thanks for the question. Gobs of years and gobs of defects later, I've realized that it's too easy to craft code that looks good but hides sneaky little defects--or just dumb mistakes.

Unit tests are at an interface level. They verify that given inputs, I end up with expected outputs and side effects. From the stance of designing methods, that should be a reasonably constrained set, and as a programmer, I'd better know what those ranges are--if I don't, I probably shouldn't be building that chunk of code. I end up with a test that states my intent in the design the code--a form of documentation on how the code behaves, not how it's implemented.

Good point about putting faith on the developer. Indeed, we also make the assumption that the developer knows what to code and how to code it correctly. I think of the tests as the other half of the entries in a double-entry bookkeeping system. The cross-checking has definitely paid off.

The book contains a few chapters on testing strategy so that you can start taking a pragmatic approach. It uses two acronyms from the original book--The Right-BICEP, which helps guide what to test, and CORRECT, which covers boundary conditions, where we tend to make more errors.

Regards,
Jeff
 
Sheriff
Posts: 17644
300
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Paul Roubekas wrote:it seems like the assumption that a developer can guess what needs to be tested puts a lot of faith on a human


One thing I have found that helps mitigate the risk of relying on a single person, i.e., a single point of failure: working closely with other developers and your users.

Working with other developers, as in doing pair programming or mob programming, really ramps up the game and allows you to inject different perspectives into the development/design process. You get more discussions about "what if" situations and hence, more ideas on how to test the system. Of course, the team members need to have good working relationships with each other and there should be a good balance of experience vs inexperience. In my experience, this kind of collaborative development that comes from pair/mob programming is usually more enjoyable and productive than solo programming. And there seems to be more motivation across the board to learn new techniques, new technologies, and even little things like keyboard shortcuts to be even more productive. It's the atmosphere of cooperative competition, I think, that drives good developers to strive to be even better when they see what their peers are doing.

Getting your users involved and engaged in making progress is the best way I have found to stay focused on what matters and on track with feature implementation. When users help write acceptance tests, they get the opportunity to share their own perspectives which can reveal other aspects of testing that developers might miss. Additionally, the users get the visibility into the progress that they so often need to feel comfortable with the schedule and any changes to it that the development team proposes, and they are better assured that they and the team are on the same page as to what should be built.
 
Would anybody like some fudge? I made it an hour ago. And it goes well with a tiny ad ...
a bit of art, as a gift, the permaculture playing cards
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic