 |
lua-l archive |
|
|
||
|
Thank you for your help, Tom.
Source control is fine. I suffered a lot with new versions that “crashes on the fly” and forced me to find where the problem was. Source control is frequent in our IT group and I agree (now) with this practice.
Have you some Lua modularity “best practices”? I think we need to write some API for each module. There are a lot of type checks? Procedural or OO modules?
Automated testing is a weak in my programming experience (Automated integration subsequently …) . I got enthusiasm using few mocks, but it is far from a good practice.
Sincerely yours,
Source control should need no explanation, but it needs to be said, because many programmers get started without using source control and never get around to using it. Also, the quality and affordability of source control systems has improved dramatically in recent years. There are multiple competing cloud hosted Git services with pull request workflows that are essentially free for most projects. There is no excuse not to be using source control.
The Lua module system is perfect for modularity. Modules abstract dependencies. The Lua module system enables service-oriented architecture, dependency injection, and programming by composition. It may be hard for people to appreciate how powerful and useful the module system is, because it is so simple.
Automated unit testing requires modularity. The code under test is isolated by replacing its dependencies with stubs or mocks. A unit test framework and a mock framework are helpful. If you don’t use an off the shelf framework, be aware that you may end up writing one. The main thing is to write automated unit tests at the same time as the code, or earlier if possible (Test Driven Development). Code coverage of 100% is achievable. If a line of code cannot be unit tested, it should be considered unreachable and deleted.
Automated integration testing is a huge area. Techniques include simulation, instrumentation, fault injection, fuzzing, and A/B testing.
HTH,
Tom