for testing, hard to tell. I would say, write test for your module.
About dev methodology … I have a couple advice.
Sit down and think about your problem. Pick one end result and go back along the technological solution. You want to write down all the pieces you need. Begin large and fairly generic, then break them into smaller more precise pieces. This is your initial architecture. It will change during the course of your project.
Do not spend a lot of time into what the pieces will do. But try to decide how they will interact with each other. What type of data need to be passed? Does data goes in only one way ? Things like that. By doing that, you are defining the limits of your parts. It can be a fairly small part, it may end up being just a couple of functions.
But the nice thing about this definition of a contract between your parts mean that you can quickly change how one part work, or test and debug that part alone without impacting the rest of your project. This should help you save time.
Another advice : it is ok to delete stuff. It is ok to have “bad” code at the beginning or even at the end if the thing works. Keep in mind that a good motto is “Make it work, then make it pretty, then, if needed, make it fast”.
My best advice for maintainable code is taken from the talk i link at the end of that post. And it is “if you cannot delete it and rewrite it all in a better way in a small amount of time, then you need to define more boundaries”.
Also feel free to ask more questions, or to join other community discussion tools Asking questions is probably the best way to both learn, and make less mistakes
The mission to write first project in new stack in clean manner is mission impossible. From the experience, I can tell you that this should be a throw away project.
Switching stacks, learning new conventions and making the thing beautiful and maintainable at the same time - all in first project. I never saw that. You can pick one or two from above, but you’d need to be super human to do all.