Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[new-backend] Fix unit tests #4487

Closed
18 of 25 tasks
eiskasten opened this issue Sep 26, 2022 · 18 comments
Closed
18 of 25 tasks

[new-backend] Fix unit tests #4487

eiskasten opened this issue Sep 26, 2022 · 18 comments
Assignees
Labels
stale testing errors in tests without implication on real usage triage needed Issue needs clarifications.

Comments

@eiskasten
Copy link
Contributor

eiskasten commented Sep 26, 2022

Lots of tests currently fail in the master branch (c560182).

Expected Result

All tests should pass

Actual Result

The following tests are failing:

The following tests are (partially) disabled:

  • 2 - testtool_backend
  • 156 - testmod_resolver
  • 239 - testshell_markdown_cache_shelltests

The state of the following tests is currently unknown to me:

  • 33 - testjna_gradle

I will add further logs and information in a comment per testsuite. This should make the discussion make much more clear. If a testsuite is fixed, it can be checked in this list.

System Information

  • Elektra: new-backend
  • Operating System: Debian Sid Container
@eiskasten eiskasten self-assigned this Sep 26, 2022
@eiskasten eiskasten added testing errors in tests without implication on real usage triage needed Issue needs clarifications. labels Sep 26, 2022
@markus2330
Copy link
Contributor

@eiskasten Thank you very much for kicking off this issue 🚀 💞

@atmaxinger can you give some input about the extra tests that failed after merging #4471?

@atmaxinger
Copy link
Contributor

testkdb_error
testkdb_nested
testkdb_simple

The problem lies in goptsActive. Previously, it was checked like this:

bool goptsActive = handle->globalPlugins[PROCGETSTORAGE][MAXONCE] != NULL;

Which doesn't really tell you if gopts is really activated, just if there is some plugin loaded there. Spoiler: the list plugin is. This with the fact that both backends are in the proc:/ namespaces led to the following block executing:

if (ksGetSize (backends) == 0 || (goptsActive && keyGetNamespace (ksAtCursor (backends, 0)) == KEY_NS_PROC &&
keyGetNamespace (ksAtCursor (backends, ksGetSize (backends) - 1)) == KEY_NS_PROC))
{
// TODO (kodebach): name not needed, once lock is in place
keyCopy (parentKey, initialParent, KEY_CP_NAME | KEY_CP_VALUE);
keyDel (initialParent);
keyCopy (parentKey, keyGetMeta (backendsFindParent (allBackends, parentKey), "meta:/internal/kdbmountpoint"),
KEY_CP_STRING);
ksDel (backends);
ksDel (allBackends);
errno = errnosave;
return 0;
}

So this is more or less a bug/works-by-accident behaviour of the new-backend branch.

@kodebach
Copy link
Member

Yes, the goptsActive check wasn't correct. But as I said in #4471 (comment) the failing tests have existed in this form since before gopts (and PROCGETSTORAGE) was a thing.

Also AFAICT 0 is the correct return value here. All these tests set up temporary mountpoints without creating the storage files. Therefore the resolver will respond with ELEKTRA_PLUGIN_STATUS_NO_UPDATE, which means there are no backends that need to be read.

What this if should check is that either we have no backend left, or the only backend left is the fake backend for gopts. Because those are the cases, where we don't need to do anything. Maybe it is also possible to move adding the fake backend to after this if. Then it would just be if (ksGetSize (backends) == 0).

@kodebach
Copy link
Member

@eiskasten there are also quite a few tests in new-backend that are commented out or disabled.

Some of them are tests for old data structures that aren't used anymore. In those cases, there might not yet be tests for the new data structures.

// FIXME: lots of commented out tests
#if 1 == 0

Other tests, check behaviour that has changed a bit

TEST_F (Simple, DISABLED_MetaInSet)
{
// FIXME (kodebach): uses non-storable namespaces

@atmaxinger
Copy link
Contributor

@kodebach do we actually have tests for the spec plugin testing the bahaviour as global plugin that I can repurpose for the hooks? The two I found (test_spec and testmod_spec) all pass. But there must be some tests in elektra that actually test the behaviour of kdbGet and kdbSet with spec, right?

@kodebach
Copy link
Member

test_spec AFAICT that's actually a test for ksLookup (more specifically the elektraLookupBySpec part).

testmod_spec that should be the main test for the actual functionality of spec.

Tests for how kdbGet/kdbSet spec don't really exist AFAIK. But all the testkdb_* do full kdbGet and kdbSet calls with really mountpoints. Some of them may also rely on spec (I haven't checked). There is also testscr_check_gen which does a full highlevel API code-generation and and application test compile and test run. That one definitely needs spec to work.

If you want tests for just the hook, you should probably copy what you did for gopts.

@kodebach
Copy link
Member

kodebach commented Sep 27, 2022

@eiskasten I'll fix testscr_check_doc and testscr_check_plugins in #4484

@eiskasten
Copy link
Contributor Author

@eiskasten there are also quite a few tests in new-backend that are commented out or disabled.

Some of them are tests for old data structures that aren't used anymore. In those cases, there might not yet be tests for the new data structures.

// FIXME: lots of commented out tests
#if 1 == 0

Other tests, check behaviour that has changed a bit

TEST_F (Simple, DISABLED_MetaInSet)
{
// FIXME (kodebach): uses non-storable namespaces

Ok, thank you, I will have a look on them.

@eiskasten
Copy link
Contributor Author

Some of them are tests for old data structures that aren't used anymore. In those cases, there might not yet be tests for the new data structures.

// FIXME: lots of commented out tests
#if 1 == 0

Do you suggest removing them? I tried to run them but they are not compiling anymore. I commented the non-compiling parts but they running them still fails due to substantial changes in the backend.

@kodebach
Copy link
Member

kodebach commented Oct 5, 2022

Yes, you can remove all tests that are related to split, trie or one of the functions in src/libs/elektra/mount.c. In many cases the functions thy test still exist (e.g. all the ones in mount.c), but aren't used anymore. Those functions can also be removed.

Instead of these tests, we now need to test the (non-static) backends* functions in src/libs/elektra/split.c and the elektraMountpointsParse function in src/libs/elektra/kdb.c. I haven't documented this new data structure yet, but the basic this:

  • There is now a KeySet * backends in struct _KDB.
  • The keys in this keyset are the parent keys of all mountpoints.
  • The values of these keys are struct _BackendDatas, which contain the data for a backend:
    • Plugin * backend is the backend plugin for the mountpoint
    • KeySet * definition is the definition for the mountpoint, i.e. the keys from system:/elektra/mountpoints/<mp>/definition but renamed to be below system:/
    • KeySet * plugins are the plugins for this mountpoint. This is based on the keys from system:/elektra/mountpoints/<mp>/plugins renamed to be below system:/. But the data is not simply copied. Instead the keys below system:/elektra/mountpoints/<mp>/plugins/<ref> are used to open the plugin defined by them and the resulting Plugin * is stored in the key system:/<ref>. All other keys are removed.
    • bool initialized is set to true when the init function of the backend plugin has been called.
    • bool keyNeedsSync is set by backendsDivide to indicate whether the backend contains at least one key with the KEY_FLAG_SYNC flag set
    • size_t getSize set by backendsMerge to the number of keys in the backend
    • KeySet * keys the keys in the backend. backendsDivide assigns these keys by dividing a KeySet * to the backends, and backendsMerge combines the keys from all backends back into a single KeySet *.

The other functions should do:

  • elektraMountpointsParse parses the keys from system:/elektra/mountpoints and returns KeySet * with struct _BackendDatas as described above.
  • backendsForParentKey takes a KeySet * with backends and finds the ones relevant to a given parent key, i.e. the ones that must be called for this parent key
  • backendsFindParent takes KeySet * with backends and finds the mountpoint of a given Key *

Note backendsMerge currently also clears KEY_FLAG_SYNC. This will probably change, see #4504 (comment) (bottom half). So tests probably shouldn't check that yet.

For backendsForParentKey and backendsFindParent only the key names are relevant. In normal operation the values of the keys would be struct _BackendDatas, but in the tests they can just be empty or simple strings. Similarly, backendsDivide and backendsMerge can use simpler input in tests. They do need actual struct _BackendData key values, but the Plugin * backend, KeySet * plugins and KeySet * definition can simply be NULL. Only KeySet * keys must be allocated and the other fields, are there anyway.

Re priorities: Adding tests for backendsForParentKey and backendsFindParent is probably most important and easiest. Next we should add tests for backendsDivide and backendsMerge. There is already a very basic test_backendsDivide in test_split.c, but we should have more thorough tests. Tests for elektraMountpointsParse should be added last, since they are the most complex to write.

@markus2330
Copy link
Contributor

@eiskasten @kodebach What can we realistically do here before the next release hopefully coming soon (January)?

@kodebach
Copy link
Member

I personally, won't have the time. Since I'm still focusing on the decisions. When those are finished (whenever that may be), I might find time. However, there is not that much left, so I believe somebody else could still make progress in January (or at least Feburary).

Regarding tests, I found these somewhat important FIXMEs:

  • test_getenv is disabled
  • Rust binding has all tests for KDB disabled
  • Tests for these plugins are disabled: conditionals, multifile, resolver (only some)
  • testscr_check_resolver is partially disabled with a reference to wresolver

There are also a few less important FIXMEs/TODOs:

  • testtool_backend (can be ignored, mounting code will be replaced anyway)
  • The libelektra-kdb functions ensureContract() and elektraMountpointsParse() and the backend plugin don't have any unit tests at all. They are only tested indirectly via the kdb and shell tests.
  • Tests for cache are disabled, since it is not implemented yet.
  • test_backends only contains a single test for backendsDivide in a single configuration. There could be more unit tests for all the backends* functions. But all of them are indirectly tested via the kdb and shell tests.

@markus2330
Copy link
Contributor

@eiskasten can you please update the top-post for which tests still need fixes?

@eiskasten
Copy link
Contributor Author

I have updated the state of the tests

@mpranj mpranj modified the milestones: 0.9.12, 0.9.13 Mar 3, 2023
@mpranj mpranj modified the milestones: 0.9.13, 0.9.14, 0.9.15 Mar 12, 2023
@markus2330
Copy link
Contributor

@eiskasten is there something that can go into the next release?

@markus2330 markus2330 removed this from the 0.9.15 milestone May 15, 2023
@eiskasten
Copy link
Contributor Author

Nothing I know about from

Copy link

I mark this stale as it did not have any activity for one year. I'll close it in two weeks if no further activity occurs. If you want it to be alive again, ping by writing a message here or create a new issue with the remainder of this issue.
Thank you for your contributions 💖

@github-actions github-actions bot added the stale label May 15, 2024
Copy link

I closed this now because it has been inactive for more than one year. If I closed it by mistake, please do not hesitate to reopen it or create a new issue with the remainder of this issue.
Thank you for your contributions 💖

@github-actions github-actions bot closed this as not planned Won't fix, can't repro, duplicate, stale May 29, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
stale testing errors in tests without implication on real usage triage needed Issue needs clarifications.
Projects
None yet
Development

No branches or pull requests

5 participants