Testing the Core.

A large part of the Netdata Agent Core is not testable, i.e. was never written with testability in mind. There are, however, some parts that are testable, in that they don't have many dependencies on other modules (they are self-contained) and testing them is a straightforward matter. The following page identifies some modules that are particularly easy (or are deemed suitable) for testing, based on their dependencies, whether they've been problematic, whether they have possibly concurrency issues, or whether we intend to extend or replace them etc.

libnetdata

module	action
adaptive_resortable_list	ok to test.
simple_pattern	investigate
url	ignore
socket	ignore, need system call mocking
buffer	low performance code, we need to test for performance too
config	probably should test
avl	no evidence of a bug, won't change it, might be good to test
dictionary	probably test
eval	had some problems, should be tested
health	should be tested
json	bigger problem, no tests for this.
locks	replace with libuv. wrapper keeps refcount for debugging race conditions.
log	had some problems with logs. let's write tests, but concurrency is hard. also: stress testing. see if we can replace it.
popen	test or replace
procfile	had some issues with procfile. this is more than proc. we need to test this.
statistical	we need to test this
storage_number	move the tests from unit_test.c to something else.
string	ignore
threads	replace this libuv threads.

Additional comments:

Within libnetdata the following tasks directly affect testability and/or {stability, maintainability} of the code.

• Unify use of json parsing/processing across the netdata daemon
• Getting rid of useless #ifdefs
• Get rid of thread cancellation because it's buggy.
• Create a mechanism to have our own reliable thread cancellation method.

Consider the testing framework and methodology of libuv as reference for our own testing.