Closed passenger94 closed 8 years ago
ccoupe
commented
8 years ago Are the tests related to issue #79? I know less than you about unit testing and rspec. All I know is that they take almost as much time to debug as the code they test. Oh, I also know that some people feel strongly about them and they think I'm behind the times for not joining that crowd,
passenger94
commented
8 years ago yes, i do understand you, i'm kind of mitigated on this, more precisely it look like it was a bit abused ... But i was looking around this because we are like 3 people on earth testing Shoes ... we added a lot of stuff lately ! The situation is prone to a lot of issues, So, i made an attempt and Boom, discovered bugs, made some known ones more urgent to care of ... Plus Shoes code is difficult to grasp, every time we add, fix stuff it's like walking on a mine field ... Yes it takes times but you gain value on the long run, and we don't need to test every single bit in memory
i do remember #79, i think the idea to slowly glide to some testing is good, but backporting entire shoes4 rspec is a daunting task... plus from the little i saw i'm not a huge fan of rspec ... but i can't claim i'm qualified to talk seriously about this
ccoupe
commented
8 years ago I do agree that tests can help understanding the code just as writing the doc first helps understand the goal/api of some proposed new feature.
i discovered that bug using the proposed tests suite ... .... Those tests and the manner to run them is a proposal. I'm using Shoes itself and shoes console to show the result of the tests, so i can have a real app to test against - Mocking a Shoes app seems a big nasty pain to me, but i'm totally new to this ! - So obviously, if proposal might be interesting, ideally we would test for availability of a Shoes app first ( ie : are we able to launch it, etc, etc... regular tests here ) then if all went well, launch shoes and run further tests (could be done on svg ... all widgets probably, to be explored) We might have some grouping for tests (svg related, video related, etc..) individual test, all tests in a row... Maybe launch a blanck app, test for slots, if ok, bring some basic ui to life, test for buttons, if ok, add buttons to gui, tests .... you get the idea If we want to test only video for example, assume everything else is working correctly, launch shoes and test widget, like the proposed draft (command line options ?)
(using unit test from ruby) The tiny video in the test folder might be too huge for git management : cloning, merging, etc... Tell me
What do you think ?
Edit: This also shed some crude lights onto the start method deficiencies ... see notes in video_vlc_01.rb (Tests folder) - there is still my pending enhancement proposal
Would be an opportunity to add colors, if at all possible, to shoes console ?
Edit2: We should not connect "destroy" event to gtk_main_quit in Shoes console, because it also kills Shoes ( how does one close that window ? tried to connect destroy event to deleteTesiObject, which seems to handle closing connections, no luck (freeze)... ? -- Edit: got it !))