StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
primarykey
Id
450279
data
AcceptedAnswerId
0
AnswerCount
0
ClosedDate
CommentCount
0
CommunityOwnedDate
CreationDate
2009-01-16T12:26:18.920
FavoriteCount
0
LastActivityDate
2011-05-24T15:42:25.483
LastEditDate
2011-05-24T15:42:25.483
LastEditorUserId
2457
OwnerUserId
2457
ParentId
383211
PostTypeId
2
Score
5
ViewCount
0
LastEditorDisplayName
text
Body
The question is a bit vague ("Erlang is concurrent, test it with Erlang!") but I'll try to elaborate a bit. Testing Erlang code can range from the straightforwardly simple (the right input produces the right output) to setting up complex test harnesses that verify your component behaves the way it should. What is best for your given situation depends totally on the requirements you have and the amount of black box / white box testing you want to do. Part of the beauty of Erlang is the ability to make concurrency transparent. Consider the following example (a function that parallelizes the summation of a list of lists): <pre><code>deep_sum(ListOfLists) -> Parent = self(), [spawn(fun() -> Parent ! lists:sum(List) end) || List <- ListOfLists], lists:sum([receive Sum -> Sum end || _ <- ListOfLists]). </code></pre> You would typically test this with a very simple EUnit test case: <pre><code>deep_sum_test() -> ?assertEqual(0, deep_sum([0, 0, 0, 0])), ?assertEqual(40, deep_sum([10, 10, 10, 10]). </code></pre> Now, let's say we have a bit more explicit API to this functionality: a process pool as argument: <pre><code>deep_sum(Pool, ListOfLists) -> distribute_lists(Pool, ListOfLists), lists:sum([receive Sum -> Sum end || _ <- ListOfLists]). distribute_lists(Pool, ListOfLists) -> distribute_lists(Pool, Pool, ListOfLists). distribute_lists([P|Pool], All, [L|ListOfLists]) -> P ! {self(), L}, distribute_lists(Pool, All, ListOfLists); distribute_lists([], All, ListOfLists) -> distribute_lists(All, All, ListOfLists); distribute_lists(_Pool, _All, []) -> ok. </code></pre> When testing this, we have to deal with faking this process pool: <pre><code>deep_sum_test() -> Pool = [spawn_link(fun() -> fake_pool(1) end) || _ <- lists:seq(1, 3)], ?assertEqual(4, deep_sum(Pool, [lists:seq(1, 3) || _ <- list:seq(1, 4)]), ?assertEqual(7, deep_sum(Pool, [lists:seq(1, 3) || _ <- list:seq(1, 7)]), [P ! stop || P <- Pool]. fake_pool(CannedResponse) -> receive {From, _L} -> From ! CannedResponse; stop -> ok end, fake_pool(CannedResponse). </code></pre> As you can see, testing concurrency programs in Erlang can take different shapes. These are extremely simple examples, but with Erlang's built in concurrency primitives it is very easy to create the kind of test harness you want, abstracting at the right levels. I usually find TDD to be orthogonal to wether you're testing concurrent code or not, so said testing techniques can be used for normal unit testing as well.
Tags
Title
singulars
PostAcceptedAnswerId
1. This table or related slice is empty.
PostParentId
1. POWhat's the best way to unit test concurrent Erlang code?
 singulars
 PostTypePostTypeId
 PTQuestion
PostTypePostTypeId
1. PTAnswer
UserLastEditorUserId
1. USAdam Lindberg
UserOwnerUserId
1. USAdam Lindberg
plurals
PostLinksPostIdRelatedPostId
1. This table or related slice is empty.
PostLinksRelatedPostIdPostId
1. This table or related slice is empty.
PostsAcceptedAnswerId
1. This table or related slice is empty.
PostsParentIdCreationDate
1. This table or related slice is empty.
VotesPostIdCreationDate
1. VO
 singulars
 PostPostId
 PO
 UserUserId
 This table or related slice is empty.
 VoteTypeVoteTypeId
 VTUpMod
2. VO
 singulars
 PostPostId
 PO
 UserUserId
 This table or related slice is empty.
 VoteTypeVoteTypeId
 VTUpMod
CommentsPostId
1. This table or related slice is empty.

Querying!

Guidance

A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.