I'm a quality hero, customer champion. Experienced software tester and newbie developer.
Okay, so I've actually been dabbling in code for a long time. I've just not gone very deep in any language .
I like this concept and pattern! Testing with production data without risking user experience.
I wonder if there there is a way to extend this to functions that have external impact. I guess that would depend heavily on the application so might be tricky for a generic solution.
Absolutely! I've focused strongly on quality for myself and my team this year and discovering Scientist has been perhaps the largest impact for our team, competing only with snapshot testing using Jest and Snapper.
I've applied to give a presentation on this subject in mid January at a large conference and I'm hopeful I'll be able to share it with more people, because it really is an interesting way of thinking.
You're spot on about the external impact aspects of this. While scientist is best suited for pure functions or things without an external impact, if you follow it to the extreme you start looking at using mock objects in production for your experiments so that they use a FakeEmailSender, for example.
Either that or Scientist forces you to structure your application in such a way that it has a lot of pure functions that can be tested. In the E-Mail example, you could structure your app in such a way that it builds an E-Mail object in one method and sends it in another, then you use Scientist to test the building of that object.
I suppose that expanding Scientist's scope forces you to follow the Single Responsibility Principle as well as encouraging Dependency Inversion.
I may write more on advanced Scientist use cases in the future.
I'm a quality hero, customer champion. Experienced software tester and newbie developer.
Okay, so I've actually been dabbling in code for a long time. I've just not gone very deep in any language .
I like this concept and pattern! Testing with production data without risking user experience.
I wonder if there there is a way to extend this to functions that have external impact. I guess that would depend heavily on the application so might be tricky for a generic solution.
Thanks for bringing this to my attention. :)
Absolutely! I've focused strongly on quality for myself and my team this year and discovering Scientist has been perhaps the largest impact for our team, competing only with snapshot testing using Jest and Snapper.
I've applied to give a presentation on this subject in mid January at a large conference and I'm hopeful I'll be able to share it with more people, because it really is an interesting way of thinking.
You're spot on about the external impact aspects of this. While scientist is best suited for pure functions or things without an external impact, if you follow it to the extreme you start looking at using mock objects in production for your experiments so that they use a FakeEmailSender, for example.
Either that or Scientist forces you to structure your application in such a way that it has a lot of pure functions that can be tested. In the E-Mail example, you could structure your app in such a way that it builds an E-Mail object in one method and sends it in another, then you use Scientist to test the building of that object.
I suppose that expanding Scientist's scope forces you to follow the Single Responsibility Principle as well as encouraging Dependency Inversion.
I may write more on advanced Scientist use cases in the future.
Great! Looking forward to hearing more from you on the topic. Would be interesting to hear about Jest and Snapper also.