Please explain further. because this is madness to give an answer to
Thank you for answers and links. I mean primarily unit testing. How to divide code into Form units, Data Modules and others?
Where to include event handlers? I hope from the outset get a sensible architecture, that make it possible to do testing.
How to make sure, that GUI code and logic are separated? I am trying to develop a double entry bookkeeping app for
small enterprises (using SQLite) on Windows.
One methodology would be to develop a bookkeeping engine with an input unit, a calculation-and-bookkeeping unit and a reporting unit, with a datamodule housing your databases, SQL queries etc with appropriate input and output APIs.
Then develop a small console testing app which uses readlns (or file reads) for input and writelns for output to stress test your engine for all likely and unlikely values.
When you have shaped your engine and probably re-designed it several times until it does what you want, you then debug it so the basic CRUD and bookkeeping operations work flawlessly,
Then design your user interface. Doing this last ensures it is properly decoupled from the data manipulation engine.
If it is a simple app, you might get away with using TDatasources, DBEdits and so on. But that is less than ideal.
You can use a ready-made ORM (there are several mature Pascal alternatives, but a learning curve of course if you have not used one before); or for a simple app you can link UI data input to your engine fairly easily using the standard edit, combo and spin edit components.