Re: How to realize different test categories?
Hello Timo,
thanks for reply.
Am 28.07.2023 14:56 schrieb Timo Röhling:
I had a look at the backintime sources, and I noticed that you
First of all: I haven't nothing. :D I'm not the founder of backintime
(BIT) just the 3rd generation maintainer trying to modernize an over 15
year old python application. ;)
implemented a very unusual (for Python, at least) build system.
Yes, pyproject.toml etc is on my list.
There are also tools for test isolation such as [2].
Tox? How can tox help me here? It is to run multiply python versions,
virtual env and things like this.
Tox, poetry etc would just make a build system more complex then it
need. Currently I see no advantage of it from upstream perspective but
I'm open to new arguments.
increasing your workload by maintaining an extra set of tests
for Debian
No, that is not how it is. It is not an extra set of tests.
In theory you have three kinds of tests: unit-, integration- and
system-tests.
To my knowledge only unittests are making sense to run on a Debian build
system using chroot.
BIT's problem is having no real unittests. But if I want to make them
accessible to Debians build system excluding the other tests.
It won't be a set of tests realted to Debian. It will just be a set of
real unittests running everywhere.
why not let backintime take advantage of established
practices and tools?
I'm working on it. But breaking the whole project structure without
knowing all details of it (because I'm not the founder) is to risky at
the current time. Maybe when Debian 14 is stable. ;)
Kind
Christian
Reply to: