multithreading - How do I test cross-thread queue? -

i not 100% sure so-adequate question, guess falls under "a specific programming problem". tips make more so-friendly welcome.

a bit of context

in dlang there no default data sharing between threads - instead use message passing. safe , clean approach is, makes hard scale our code horizontaly. best example multiple writer - multiple reader problem - gets quite complicated when using std.concurrency.

quite common way solve problem use in-memory queue - writers push queue, readers pull it, each thread runs on own pace, , bob's uncle. so, i've decided implement queue dlang myself.

the code

queue has following api:

module javaesque.concurrency;  queue!t queue(t)(){     // constructor, out of struct implementation sake }  struct queue(t){     // internals not important sake of question      void push(t val){     // ...     }      t pull(){     // ...     } } 

and here's sample app using that:

// import whatever's needed, stdio, concurrency, etc  void runnable(queue!string q){     try {         while (true) {             writeln(to!string(thistid)~" "~q.pull());         }     } catch (ownerterminated ot) {     } }  void main(string[] args){     queue!string queue = queue!string();     spawn(&runnable, queue);     spawn(&runnable, queue);     (int = 0; i< 20; ++i){         queue.push(to!string(i));     }     readln(); } 

question

ok, how test that? while prototyping tested running sample app, i've confirmed idea may work expected, want write unit tests. how?

please keep in mind didn't add dlang or related tags question. though i've supplied snippets in dlang , background highly d-related, looking general on testing kind of structures, without constraining myself language. obviously, general answer dlang-specific addition welcome, question should treated language-agnostic.

well, "generic" approach testing two-fold:

• you focus on public contract of constructs, , think testcases test each aspect of contract
• you focus on inner implementation , think of (additional) test cases specific corner cases

and beyond that: first test whole construct in single threaded manner. similar things same thread service: setup environment effectively use 1 thread only.

that might sufficient "most" of code - might fine few "integration" tests test one expected end end scenario (using multiple threads). there test example multiple readers receive expected result in end.

finally, angle: key unit tests write code can unit tested easily. need able @ different units in isolation. if provide code here, rather turn codereview request (which wouldnt belong here).