How many kernel test frameworks?

>it is the difference between unit tests and functional tests
Conventionally, unit tests *are* functional tests. Harnessing program logic in its own scope is unit testing; the tests themselves measure* the functionality. You're also mistaking the API conformity suite for being unit tests: they're integration tests simply becuase they ask "will these components play nicely together?"

> And for this point there might be need for a third framework to keep things clear and avoid getting a bloated framework or unreadable/unmaintainable tests.
Convention holds that the phrases you want to use are 'separation of concerns' for having tests appropriate to the layer of production functionality you want to measure* and 'single responsibility principle' for having production and test code do only one thing (hopefully well) -- and that single responsibility for the test code is to measure* the outcome of a single change in one layer of the system.

*: I've starred 'measure' each time I used it because I talk about testing in terms of taking measurements aimed to accept or reject a falsifiable hypothesis about the system. We talk about preparing the system, then making a single change, and measuring the impact. And we also talk about the layers of these tests: the 'testing pyramid' I prefer to use is one of a base of super-quick and super-numerous, whose output you trust when assessing whether the components will integrate properly as their interfaces work to explicit interface contracts, and then external interfaces (user and programmatic) becoming more expensive because they require more setup and levels to the stack to be representative of real-world use (which is balanced by the harness being lightweight because you're building on the trust of the lower levels of your testing); and finally, the smoke tests of "did we deploy it right?"

K3n.