On Tue, Jul 9, 2019 at 5:20 PM Jesse Glick <jgl...@cloudbees.com> wrote: > > On Tue, Jul 9, 2019 at 4:47 PM Ullrich Hafner <ullrich.haf...@gmail.com> > wrote: > > This topic reminds me of one of my architecture guidelines I’m presenting > > students in my testing lecture: > > An application should always provide a way to change (or inject) […] > > If you are enumerating design flaws in Jenkins APIs which hurt > testability, you are going to have a very full syllabus. :-)
We can start with one simple yet permeating issue: an aversion to inversion of control. I've found that working in pure functional programming for a short period of time is enough to help one grasp the level of implicit dependencies you took for granted (e.g., having a Clock, standard in/out/err or similar streams, other implicit state) as well as a desire to hide these unnecessary details in a more natural way. If you can modify the code you're testing, I'd suggest injecting a java.time.Clock into classes that are checking the current time. Then you can trivially mock the Clock instance in your tests. If you want to do this the "Jenkins Way", throw the Clock into a singleton that's updated by JenkinsRule like Jenkins' own Jenkins instance. -- Matt Sicker Senior Software Engineer, CloudBees -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAEot4oyk_vuWmgOOEjAS1pA9R3tiuBo23cNkAZpmsj%2BXSvyiag%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
