Compatibility tests #1788
No reviewers
Labels
No Label
bug
build
dependencies
developers
documentation
duplicate
enhancement
formatting
invalid
legal
mobile
obsolete
packaging
performance
protocol
question
refactoring
regression
security
test
translation
usability
wontfix
No Milestone
No project
No Assignees
1 Participants
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: Bitmessage/PyBitmessage-2024-12-22#1788
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "compatibility"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Hello!
Let's introduce some simple compatibility tests, based on a sample data and well known values. I wish them to cover the implementations of all the functionality, defined in the protocol. So that an alternative implementation can take the samples to check it's compatibility.
It's also helpful for the ongoing python3 porting. Because most of the developers are not writing any tests. And I've already found a feature in
highlevelcrypto
module, which I don't yet understand, but I think that such incompatibilities is better to reveal soon. The test shows that not all the subset ofpyelliptic
is used inhighlevelcrypto
in compatible way with python3.And of course the check's gonna fail.
It's even worse: apparently the
pyelliptic
is not python3 compatible. It's just not covered with tests.solved it in the recent code: https://github.com/g1itch/PyBitmessage/runs/3182720003#step:8:70
Maybe this shouldn't be called "Compatiblity tests" as most of it is network subsystem refactoring. Could you perhaps put the (smaller) protocol refactoring into a separate PR, and just keep this for the network subsystem? Then the protocol refactoring can be merged earlier and faster.
maybe also "random" refactoring separately.
I see, the rest of this branch is currently a complicated changeset merged from different branches with pretty controversial changes mixed with a few tests. I'm slowly reading the other part of the implementation in search of a pieces, which I can isolate clearly and cover by tests. Unsuccessfully so far.
Maybe I'll rebase the branch, if I found a way to write cleaner set of tests for the significant portion of the protocol. But the overall idea of those "Compatiblity tests" is covering the protocol structures, excluding those related to crypto operations (the #1796 part).
Yes, the random is probably closer to the refactoring of the crypto operations. But this particular approach is a bit problematic, so I don't merge those changes into the crypto branch and so far neither I see a way to isolate the related changes into a separate PR. So I'm going to rename the branch and replace it by the further changes when they are ready.