Hey Pradeepa,
I would strongly suggest against trying to use TDD with multiple
threads active. Instead, I would design your system such that as much
as possible of the inter-thread communication does not really need to
be tested directly. One way of doing this is to create well-defined
abstractions for thread interactions that you can mock out so that you
can test each thread in isolation while modeling its interactions with
the rest of the system.
For example, you could use message queues as your main method of
inter-thread communication. This will allow your tests to inject
messages into your thread's queue and observe messages dispatched from
your thread. By providing a good abstraction for the message queue you
should also get the side benefit of greater portability by being less
tied to any particular OS/RTOS.
This isn't always easy or even possible (particularly if you're trying
to add testing to a legacy system), but if you can go this route it
will be far less painful than trying to get CppUTest running in a
multi-threaded environment while still having a test system that
normal humans will be able to reason about.
Ryan
> --
> You received this message because you are subscribed to the Google Groups
> "cpputest" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to
cpputest+u...@googlegroups.com.
> For more options, visit
https://groups.google.com/d/optout.