3

I have a few methods that are impacted by concurrency. Specifically "Rush" (a.k.a Race) conditions. Should I unit test them or integrate/black-box test them?

I think that setting up a unit test might be a rather difficult task, but also is integration test...

Improve this question
3
  • @rene race conditions, I guess Commented Dec 31, 2013 at 17:50
  • Also I don't think it's possible to test that explicitly. Maybe some integration tests that will sporadically fail Commented Dec 31, 2013 at 17:53
  • Relevant question over at programmers SE: programmers.stackexchange.com/questions/196105/… Commented Dec 31, 2013 at 18:02

2 Answers 2

Reset to default
4

Unit tests must be deterministic, so concurrency doesn't belong there. (I keep my unit tests completely synchronous.)

Go for integration tests to sniff out race conditions — but be prepared for false positives. In other words, the tests passing is no proof that you don't have a race condition. But a failure will alert you to something you need to fix.

Improve this answer
Sign up to request clarification or add additional context in comments.

Comments

1

i've found this article and its quite instructive about my question: https://testing.googleblog.com/2014/02/minimizing-unreproducible-bugs.html

Improve this answer

Comments

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.