-
Notifications
You must be signed in to change notification settings - Fork 15
Open
Description
Hi guys,
I don't know where is better to start this topic, so let it be here.
I have read Atomic API RFC, and the followed discussion; however, I am not sure that I fully understand everything due to lack of theoretical knowledge and practical experience in writing highly concurrent DS and algorithms, and I want to participate in the development of this crate.
But I have some experience in writing tests with production code. (I don't want to argue what is better test first or test last.) But, I have some thoughts how to use tests in development of crossbeam:
- add an optional section "How we will test this" (or any other name you would like) to the RFCs that propose new or change existed functionality. That section would contain a list of stress test scenarios, maybe with a brief description of the tests and what kind of load should be (and people like me, would be able to build a context around the problem, and maybe bring some new ideas or suggestions)
- include unit tests for single threaded scenarios to implementations of the RFCs. I know this is very personal, but I see some advantages of this. First of all, it is very useful for library developers to taste its API with the tests (It can bring whole new ideas what API should be). Second, it is very convenient to library users to see how they can use API (maybe I am the only one who looks for examples of API usage in tests). And, maybe, the most important that reviewers can spot that some cases weren't covered and needed more attention.
Metadata
Metadata
Assignees
Labels
No labels