How to properly write tests for kernel functions
Hi all, I'm trying to understand is there any uniform way to write tests? For example, lib/ folder has a bunch of tests, but all of them use various technics: - pr_warn/pr_err (i.e. printk) or WARN for assertions - just tens of functions that check something, or unified macros - no naming convention for test cases So, I'm wondering, whether there is an example or guidelines that is worth to follow. Thanks!
On Thu, Nov 05, 2015 at 12:26:01AM +0300, Maxim Pugachev wrote:
Hi all,
I'm trying to understand is there any uniform way to write tests? For example, lib/ folder has a bunch of tests, but all of them use various technics:
- pr_warn/pr_err (i.e. printk) or WARN for assertions - just tens of functions that check something, or unified macros - no naming convention for test cases
So, I'm wondering, whether there is an example or guidelines that is worth to follow.
It all depends on what you want to test. There is no "general" way to do this as all subsystems / parts of the kernel are different. thanks, greg k-h
So, I'm wondering, whether there is an example or guidelines that is worth to follow.
It all depends on what you want to test. There is no "general" way to do this as all subsystems / parts of the kernel are different.
I'd like to add more tests in lib/test-hexdump.c. To my mind, I have 2 options: follow the current style, or perform a bit of reorganization. I'm inclined to the second one given that the addition of new tests may lead to unreadable code. But I doubt which way is better in this case.
On Thu, Nov 05, 2015 at 11:43:36AM +0300, Maxim Pugachev wrote:
So, I'm wondering, whether there is an example or guidelines that is worth to follow.
It all depends on what you want to test. There is no "general" way to do this as all subsystems / parts of the kernel are different.
I'd like to add more tests in lib/test-hexdump.c. To my mind, I have 2 options: follow the current style, or perform a bit of reorganization. I'm inclined to the second one given that the addition of new tests may lead to unreadable code. But I doubt which way is better in this case.
It's up to you, but if you do reorganize the code, do that in a patch series that changes the structure before adding new tests, in order for them to be accepted upstream. good luck! greg k-h
On Thu, Nov 5, 2015 at 10:54 PM, Greg KH <greg@kroah.com> wrote:
On Thu, Nov 05, 2015 at 11:43:36AM +0300, Maxim Pugachev wrote:
So, I'm wondering, whether there is an example or guidelines that is worth to follow.
It all depends on what you want to test. There is no "general" way to do this as all subsystems / parts of the kernel are different.
I'd like to add more tests in lib/test-hexdump.c. To my mind, I have 2 options: follow the current style, or perform a bit of reorganization. I'm inclined to the second one given that the addition of new tests may lead to unreadable code. But I doubt which way is better in this case.
It's up to you, but if you do reorganize the code, do that in a patch series that changes the structure before adding new tests, in order for them to be accepted upstream.
good luck!
Greg, thank you for your answers!
participants (2)
-
Greg KH -
Maxim Pugachev