On Fri, Jul 10, 2020 at 4:58 AM Richi Dubey <richidu...@gmail.com> wrote: > > Hi, > > Thanks for the suggestions, they're all very valid and helpful. > >> We advocate a test-driven development (TDD) approach in RTEMS. Write >> the test that should pass once your implementation is correct. Making >> it multi-layered from simpler to more complex functionality allows you >> to keep track of your progress and make sure you don't break something >> (regression) that was working earlier. > > > Should it be a complete test suite like the ones in the folder smptests or > should it just be an idea in the Doxygen comment? >
For TDD you need to have a real test. > On Thu, Jul 9, 2020 at 8:27 PM Gedare Bloom <ged...@rtems.org> wrote: >> >> Richi, >> >> Some good advice from others. I'll just add a few more notes. >> >> On Thu, Jul 9, 2020 at 2:23 AM Richi Dubey <richidu...@gmail.com> wrote: >> > >> > Hi, >> > >> > I understand. I'll learn how to use Doxygen and put it in my codes. Thank >> > you. >> > >> Not just that, he also suggests you can start with a doxygen >> description before you really start coding. This is useful to help >> think through the interfaces and structures of your functions before >> you start to implement them. >> >> If you need help to run doxygen locally, ask. >> >> > On Thu, Jul 9, 2020 at 12:43 PM Sebastian Huber >> > <sebastian.hu...@embedded-brains.de> wrote: >> >> >> >> Hello Richi, >> >> >> >> we use Doxygen to document the software design. Maybe you can write your >> >> high-level description with it. This way it is integrated already >> >> integrated in the sources. You can use @dot for graphs and @msc for >> >> message sequences. >> >> >> >> Personally, I like to start with pen and paper drafts in a notebook. I >> keep my notebook handy to keep track of revisions and ideas. I'll move >> to either text- or graphic-based design if I need to share it with >> others. Text-based is easier to integrate in documentation, while >> graphic-based can make for some really nice explanations in blogs and >> other reports. Doing text-based in doxygen is a good way to save time >> on internal doco later. >> >> >> I would document the data structures and the invariants of the data >> >> structures. I would also try to write code which checks that the >> >> invariants are satisfied. This can be used in _Assert() and RTEMS_DEBUG >> >> blocks. >> >> >> >> I would also write test cases. You can already run the test cases with: >> >> >> >> https://docs.rtems.org/branches/master/c-user/scheduling_concepts.html#arbitrary-processor-affinity-priority-smp-scheduler >> >> >> >> We advocate a test-driven development (TDD) approach in RTEMS. Write >> the test that should pass once your implementation is correct. Making >> it multi-layered from simpler to more complex functionality allows you >> to keep track of your progress and make sure you don't break something >> (regression) that was working earlier. >> >> >> There should be test cases which would fail with the Linux push and pull >> >> scheduler. >> >> >> >> You should identify the key scheduler operations (e.g. block and >> >> unblock) and write a high level description of the algorithms used for >> >> these operations in some sort of pseudo code. >> >> >> >> -- >> >> Sebastian Huber, embedded brains GmbH >> >> >> >> Address : Dornierstr. 4, D-82178 Puchheim, Germany >> >> Phone : +49 89 189 47 41-16 >> >> Fax : +49 89 189 47 41-09 >> >> E-Mail : sebastian.hu...@embedded-brains.de >> >> PGP : Public key available on request. >> >> >> >> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. >> > >> > _______________________________________________ >> > users mailing list >> > users@rtems.org >> > http://lists.rtems.org/mailman/listinfo/users _______________________________________________ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
