We can only do so much from the application, we want to have some unit tests for the hardware drivers, that we will also hook to our internal CI.
The driver can be instantiated and instead of binding it with an upper layer we use it as part of our testing. We can then have boards' entry points that run the unit tests. At least this is the idea so far. On Mon, Dec 28, 2020 at 8:22 PM Brennan Ashton <bash...@brennanashton.com> wrote: > > You would need to explain more. It would be very difficult to separate the > drivers from the underlying hardware interface. What exactly are you > wanting to test? You can always violate the kernel boundary for testing > much like is done with some of the other tests in apps. > > On Mon, Dec 28, 2020, 11:13 AM Abdelatif Guettouche < > abdelatif.guettou...@gmail.com> wrote: > > > The interface is actually configurable. > > > > We want to use that for some unit testing for the drivers, any > > alternatives? > > > > On Mon, Dec 28, 2020, 20:05 Gregory Nutt <spudan...@gmail.com> wrote: > > > > > Unity also uses application only interfaces such as printf() that would > > > be inappropriate for use within the OS. > > > > > > On 12/28/2020 1:00 PM, Brennan Ashton wrote: > > > > I don't think so any testing will be part of an application. There is > > > > nothing in the OS that would ever make use of it directly. Even if you > > > > were to make something like ostest use it the right place would still > > be > > > as > > > > an application. > > > > > > > > --Brennan > > > > > > > > On Mon, Dec 28, 2020, 10:40 AM Abdelatif Guettouche < > > > > abdelatif.guettou...@gmail.com> wrote: > > > > > > > >> Unity (https://github.com/ThrowTheSwitch/Unity) is a test harness > > that > > > >> we can use both for applications and OS code. Isn't it better to have > > > >> it in libs/libtesting instead of apps/testing? > > > >> > > > > > > > >
