How does regeneration deal with persistent state? If a **plain change leads to a different DB schema, does turri generate migrations, or is the data layer treated as something that can’t just be thrown away? This has been the hardest part for me with spec-first generation.
Yes, turri will generate migrations with every change, so if you need to deploy a new version it will check against the current schema and generate it properly.
Honestly, I haven't used it on some reasonable scale to fell the real issues of migrations yet. I consider this to be one of the biggest problems with the approach, but I think it's addressable.
I consider this to be the most important concept of the regenerative software approach. Basically, if you can regenerate a certain module multiple times you are certain that you nailed down every detail that are describes that module.
If this is true, it means that each new change in the system can be reliably described with a small change in the system knowledge (usually it includes some small update in specs and tests) and regenerate with very high certainty that the produced code will be correct.
Basically, the regeneration test is putting a solid ground for all future improvements.
First, it automatically confirms that all defined tests are passing but it's hard to say if the defined tests are covering all the edge cases that are important.
It will also write a bunch of mutation tests and do the automatic tests based on the type of application.
At the end, you would still need to manually check to confirm the functionality (unless until you are confirming inital deletion test for a certain module).
How does regeneration deal with persistent state? If a **plain change leads to a different DB schema, does turri generate migrations, or is the data layer treated as something that can’t just be thrown away? This has been the hardest part for me with spec-first generation.
Yes, turri will generate migrations with every change, so if you need to deploy a new version it will check against the current schema and generate it properly.
Honestly, I haven't used it on some reasonable scale to fell the real issues of migrations yet. I consider this to be one of the biggest problems with the approach, but I think it's addressable.
How do you approach this problem?
How do you enforce the deletion check? I understand that it is important to make sure the regeneration can be trusted but do I really need that?
I consider this to be the most important concept of the regenerative software approach. Basically, if you can regenerate a certain module multiple times you are certain that you nailed down every detail that are describes that module.
If this is true, it means that each new change in the system can be reliably described with a small change in the system knowledge (usually it includes some small update in specs and tests) and regenerate with very high certainty that the produced code will be correct.
Basically, the regeneration test is putting a solid ground for all future improvements.
Ok, that makes a lot of sense. But how do you do it in practice? How do you test if the spec passes the deletion check?
Through multiple steps I would say.
First, it automatically confirms that all defined tests are passing but it's hard to say if the defined tests are covering all the edge cases that are important.
It will also write a bunch of mutation tests and do the automatic tests based on the type of application.
At the end, you would still need to manually check to confirm the functionality (unless until you are confirming inital deletion test for a certain module).
Check Chad Fowler's The Phoenix architecture series for more information on regenerative software: https://chadfowler.com/regenerative-software/
Really interesting idea. We need more tools like this to see if regenerative software actually works in practice. Nice to see someone trying it.
While building turri, I build quite some internal tools that I'm still using. I'm planning to open-source some of them.
Please, try it yourself and let me know what you think.