On Thursday, October 22, 2015 at 8:11:46 PM UTC+11, David Schmitt wrote: > > fakes/mocks in s/w development have a very limited scope: usually only one > or two methods with pre-defined return values. If you really do not want to > test integration with a certain service, perhaps making that explicit and > having a test version of a profile that does not include the FreeIPA > support makes sense? It would also ensure that other services (like SSO on > the apache ??) do not depend too heavily on FreeIPA. > > It reminds me a bit of Aspect Oriented Programming, where cross-cutting > concerns are extracted from the code and re-injected by the compiler in a > uniform way across the board. >
Actually, I have worked on a number of projects in my time where developers did mock up some reasonably complex fakes for integration testing. I have been thinking about this more. At the moment, integration tests are limited because Beaker does not allow us to modify either the source manifest code or the compiled catalogs under test. We had a flow like: Beaker --> provisioner (vagrant, vSphere etc) --> Serverspec Could we instead have something like: Beaker --> Rspec-puppet (possibly producing modified catalogs) --> provisioner --> Serverspec We have so much awesome functionality in Rspec-puppet but the big gotcha is that we have no way of testing the catalogs that it produces on real systems. Could I be onto something here? -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/de2ab5b7-a9d9-405d-9211-9f1f5b1bb72f%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
