Guest User

Untitled

a guest
Jan 19th, 2018
76
0
Never
Not a member of Pastebin yet? Sign Up, it unlocks many cool features!
text 2.16 KB | None | 0 0
  1. # A Unit Testing Analogy for Non-Developers
  2.  
  3. Our organization is in the midst of a push to improve the state of unit testing. I had thought I communicated the need for unit testing well and explained its importance sufficiently, but I attended a meeting recently that made me realize I still had much work to do.
  4.  
  5. ## Organizational Background
  6. The IT organization is largely driven and managed by non-developers. Our processes regard developers as "resources" who are procured, managed using rigid enterprise-wide processes, and expected to produce features. As such, code is not well-understood beyond the tacit acknowledgement that code needs to be written in order to build a feature. The fact that code accrues, that a unit test written during a user story has benefit for the development of future stories, and that overall code quality has a signficant impact on a team's ability to enhance a system safely and productively is largely lost in the sea of contracting and project management best practices. Sure, there's evidence of technical debt in that teams need more story points to deliver features than they did in the past, but it tends to bring more scrutiny to the team than the underlying code and architectures ("Our product owners aren't getting the same level of feature roll-out as they did in the past--perhaps it's time to change contractors?").
  7.  
  8. ## The Meeting
  9. A brownfield project to enhance a legacy system was about two thirds completed and the project team met with me seeking a waiver for the "requirement to write unit tests" for the following reasons:
  10. 1. The current codebase was not set up for automated unit testing and had never had any unit tests before. Given that the system has always been relatively stable, why bother?
  11. 2. Being forced to write unit tests would slow down development progress and put the project at risk.
  12. 3. There was another, more comprehensive enhancement project scheduled after this one--that would be a more appropriate time to start writing unit tests.
  13. 4. They were already testing things manually. In fact, there were three rounds of manual, functional testing scheduled in the upcoming month.
  14.  
  15. I took exception to all of their arguments.
  16.  
  17. ## The Analogy
Add Comment
Please, Sign In to add comment