Add functional tests #182
Add functional tests #182
Conversation
MrDOS
force-pushed
the
add-functional-tests
branch
2 times, most recently
from
5e4a04c to
d0ff075
Compare
|
In comparison to the state of the branch when I made the pull request, this now has some additional tests (of control line behaviour, and of flow control), and has been tested on macOS and Linux in addition to Windows (and works around platform discrepancies accordingly). I'm going to put this down for now and get back to my JNA experiments, but please share any thoughts. The more I look under the hood of the project, the more refactoring opportunities I see. But as much as I'd like to tackle them, I'm not really comfortable doing so without better infrastructure to help avoid regressions. I see this as a pretty necessary step in the direction of a cleaner, more easily modifiable codebase. |
|
Awesome! Do any of these need hardware attached to run? Since this is a hardware interface lib, is there some way to test any of that? |
|
Yeah, all of these but one require two serial interfaces to be connected to each other via a null modem cable. The tests pick up the names of these ports from environment variables. See the comment at the top of |
The read/write test expects to be configured (via environment variables; see the `SerialPortExtension` Javadoc for details) with the names of two serial ports connected to each other with a null modem cable. Armed with this hardware, it verifies basic read/write functionality of the library across a range of baud rates, and using both block and byte transfers. The identifier test merely verifies a non-null response. Not terribly useful at present, but I hope to use it to validate that the ports configured for the other test are reported correctly (assuming that the user configured them correctly, of course).
MrDOS
force-pushed
the
add-functional-tests
branch
from
d0ff075 to
3827ba0
Compare
|
I've bumped this back to a draft because the tests don't seem stable on macOS (the flow control tests return different results practically every time you run them). While that is to an extent the point of tests, I'd like to at least narrow down the problem a bit more first. And depending on where #194 goes, the tests might need to be updated to use SLF4J instead of java.util.logging. |
This pull request moves the test directory out of the root to the more conventional
src/test/java, updates the JUnit dependency from v4 to v5, and adds the first of what I hope to be several tests around core functionality.As I progress in my JNA porting project, I'm rapidly approach a point where I'm going to need to actually run what I'm working on. I could do that manually, but on the other hand, I think it would be pretty swell if there were a reasonable set of automatic tests I could run. The key word there being “automatic”: as far as I can tell, the existing tests were intended to be run manually. I'm hoping to improve on that by making at least simple test cases run themselves. As described in the commit message of 1bf18bf and the
SerialPortExtensionJavadoc, this is accomplished by having two serial ports connected via a null modem cable available on the machine running the test; the tests can then control both ports, and talk to themselves. I think this is a hardware configuration that most people using a serial port library should be able to assemble pretty easily; importantly, I think it's also a hardware configuration that QEMU can emulate, so automating cross-platform testing should eventually be possible too.Feedback is, of course, welcome. I'd really like your opinion, @madhephaestus, before I push on one way or another.