tests: assert nothing goes to stdout

[nrc]

Since LS protocol clients will choke if anything gets on to stdout other than proper protocol stuff, we should check we don't accidentally do this in tests. I think the way to do that is to capture stdout some how and check we don't write to it.

[bruno-medeiros]

Could using Stdio::lock() work for that, by spawning in another thread? If an extra thread locks stdio, then the tests would timeout if they attempt to print to stdout.

I tried this code, but it didn't work (i'd expect it to block forever but it terminated: )

fn main() {
    use std::sync::Mutex;
    use std::sync::Arc;
    
    let mutex = Arc::new(Mutex::new(()));
    let mutex2 = mutex.clone();
    let guard = mutex.lock().unwrap();
    
    let stdout_thread = std::thread::spawn(move || {
        let stdout = std::io::stdout();
        let stdout_lock = stdout.lock();
        
        mutex2.lock().unwrap();
        println!("{}", "UNLOCK");
    });
    
    println!("{}", "END");
}

[nrc]

that's a neat idea! I've never actually used stdout.lock(), so I'm not sure if/how to make this work, but it sounds feasible.

[bruno-medeiros]

Yeah it should work. I just realized my snippet wasn't working as intended (I expected it to block) because println!("{}", "END"); runs before the Stdout lock is aquired. If an std::thread::sleep(std::time::Duration::new(1, 0)); is added before the println, then it runs as expected (the purpose was just to test that stdout.lock() works as intended.

In a normal test code, the test would run and then release the mutex lock, so that then the stdout_thread would then unlock stdout. (which if all went well, should not have been written to during the test).

PS: Duh, I could written simply println!("END"); 😴

[Nashenas88]

Rather than relying on timing (which can magically fail much, much later) why not do some simple message passing after the lock has been acquired? Then it's always guaranteed to wait for the lock to be in place before it attempts to print? Or would this not work across lots and lots of tests?

[bruno-medeiros]

Rather than relying on timing (which can magically fail much, much later) why not do some simple message passing after the lock has been acquired? Then it's always guaranteed to wait for the lock to be in place before it attempts to print? Or would this not work across lots and lots of tests?

Just to be clear, I was in no way suggesting the actual test code should use thread::sleep, that's a pretty bad way of doing things.. 😓

The example above (and actual test harness) would be much better written with the Rust equivalent of Java's CountdownLatch, that would be one way of doing things in a proper way. I couldn't find any direct equivalent in Rust to CountdownLatch though - so it might have to be built using other synchronization primitives (Condition Variables?). Or something else entirely used instead of CountdownLatch.