May 11, 2020 Re: Integration tests | ||||
---|---|---|---|---|
| ||||
Posted in reply to aliak Attachments:
| On Wed, 2020-04-22 at 11:19 +0000, aliak via Digitalmars-d-learn wrote: > On Wednesday, 22 April 2020 at 10:32:48 UTC, Russel Winder wrote: > > Now I discover Python, Rust, and Go have far nicer abstractions for writing Internet code than D does. Does D really not have a TcpListener abstraction? > > It really doesn't :( :-( Even GTK+ has it's own wrappers around the base socket API to make it sensible for programmers. GtkD offers these for GtkD-based applications, but D has no language support for asynchronous (via Futures/Promises/event loops) which leaves Rust (and Python) far ahead in this race to support asynchronous programming. > And D has so much potential as server tech with the potential combination of fibers + TLS + shared + static introspection. Potential is necessary but not sufficient. Vibe.d seems to be one solution (in the Rust Async_std and Tokio sense) but Rust has language level support for Futures that make everything a lot easier in Rust than seemingly in D. > The package Vibe-d is quite nice though. I don't know if you've tried it but it's very simple to get a listener up with it. And now it seems we have Hunt. I am now dithering whether to use Vibe.d or Hunt for my async TCP (but not HTTP(S)) server. […] -- Russel. =========================================== Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Road m: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk |
May 11, 2020 Re: Integration tests | ||||
---|---|---|---|---|
| ||||
Posted in reply to Russel Winder | On Wednesday, 22 April 2020 at 10:32:48 UTC, Russel Winder wrote: > I ended up creating the following project structure: > > . > ├── dub.sdl > ├── dub.selections.json > ├── source > │ ├── arcam_protocol.d > │ └── main.d > ├── tests > │ └── integration_tests.d > └── test_support > └── mock_avr850 > └── main.d > > with the following Dub control file: > > name "arcamclient" > description "arcamclient is a Rust/gtk-rs/GTK+ desktop application to control an Arcam amplifier over the Ethernet connection." > authors "Russel Winder" > copyright "Copyright © 2020 Russel Winder." > license "GPL-3.0" > targetType "executable" > targetPath "bin" > > configuration "application" { > } > > configuration "unittest" { > targetName "arcamclient_test" > dependency "unit-threaded" version="*" > mainSourceFile "bin/ut.d" > excludedSourceFiles "source/main.d" > preBuildCommands "$DUB run --compiler=$$DC unit-threaded -c gen_ut_main -- -f bin/ut.d -d $DUB" > preBuildCommands "$DUB build arcamclient:mock_avr850" > importPaths "tests" > sourcePaths "tests" > } > > subPackage { > name "mock_avr850" > targetName "mock_avr850" > targetType "executable" > targetPath "bin" > sourcePaths "source" "test_support/mock_avr850" > importPaths "source" "test_support/mock_avr850" > excludedSourceFiles "source/main.d" > } > > This seems a bit more sensible that what I have been able to achieve with Rust, but is still second rate compared to how easy things are using Python. > Have you try Silly? I found far more straightforward to use, that unit-threaded. On my pet game engine, I got it working with this : "configurations": [ ... { "dependencies": { "beep": "~>0.0.2", "silly": "~>1.0.2" }, "name": "unittest", "targetType": "library" } ], Sadly, Silly only is the test runner (and one far prettier that unit-threaded). I need to add separated dub module to make assertion more easy and fluent. Beep go on the correct path with a API like this : @("My test") unittest { myFunc(1, 2, 3).expect!equals(42); auto a = [1, 2 ,3]; a.expect!contains(2); a.lenght.expect!great(0); true.expect!true(); } And the output on case of fail, shows a human friendly message with the expected value and the real value. Another assertion module that not depends on unit-threaded and have better API, is pyjamas . But actually is abandoned. I did a try to get it working again, but depends on another dead dub module... another test runner called "bed" (that I did a PR to fix it to get it working against the actual DMD version). Finally... What I really miss are two things : - A test/integration framework like Spock (Yeah, I professionally work on Java world :( ) - Test runners had a common output format that make IDE/tools work far more easy. See https://github.com/nomad-software/dunit/issues/19#issuecomment-435209223 Offtopic: Should be a way to mark a dub module dead on dub register. This last weeks I don't stop of finding dead/not working stuff and given a really bad image of the state of D. |
Copyright © 1999-2021 by the D Language Foundation