You want agile and test driven development.
Once you have a working prototype you collect user stories to modify the prototype. Clean up your code and move it towards solid principals using TDD.
Once you have a working prototype you collect user stories to modify the prototype. Clean up your code and move it towards solid principals using TDD.
TDD - write test before writing code. Only problem is coding is as much as discovery as implementation. You almost never construct the right structure, functionality and system the first time. It's only after you have played around that you start to understand the system and close in on something concrete. Writing tests in beginning would require you to visualize all the steps, instead of try and see approach. And you can visualize only so much. So TDD will prevent you from approaching to good solution and cause lot of wasted work. Tests should be testing integration or if unit tests then after code has been finalized.
Agile - this literally serves no purpose. If you are done with task you can move onto next task. Scoping some set of tasks to some duration of time is pointless exercise as you have no idea how much time tasks are gonna take. Estimates are notoriously bad. Quality suffers, tech debt multiplies and developers become impassionate who have no agency over their work. Agile creates these crude deadlines which means you add this artificial cool down and warm up time. If you finish early you can't start looking into something next, as you don't who will get the ticket. If you are bit late now next sprint is even more loaded.
Continuous Development - going back to 1st point, code is experimenting if you are pushing all your changes live 24/7 into master branch then you're going to end up in situation where the old code which you have decided to refactor/discard is now being used by someone else and you need to touch code that you had nothing to do with and have no context about either. If you had pushed only finalized changes then if others were to use your code they'd know it's stable. As for merge conflicts, only difference between CD and branching method is that in CD you just trade solving merge conflict at the end to solving it every day. Git history becomes so convoluted that you don't even know how to undo it because 3 peoples have been working in same file and pushing every few hours.
Tests should test a specific business goal. You know what the goal is before you write any tests right? Otherwise why are you writing any code?
OP I agree with malthuswaswrong. About TDD, not malthus, I do not know who that is.
In your case, you need only the later.