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.
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.