Repository navigation
Option for running tests on same thread as output thread #103
Description
If you drop a putStrLn or traceM into the middle of a test, you'll get output like this:
readFeed with real data: E n v e l o p e { e I d = U r l { u r l H e a d = F u l ly[u3a2l;i2f2imedO K"h[tmp"(3U2r;l2H2omst ({0u.h0H2oss)tN[mme [ 3"2a;p2i2.mlo
ca[hmos t .riemavdu .pcaogmi"n,a tuehdP ofrete d=: 0 , u h U s e r N a m e = " " , u h P a s s w d = " " } ) , u rlPath = ["feed","feed-personal-10000"], urlQuery = Nothing, urlHash = Nothing}, ePrimary = EntityBody {eData = EntityData (Object (fromList [("type",String "personal")])), eRelations = fromList [("feed_elements",Url {urlHead = FullyQualified "http" (UrlHost {uhHostName = "api.localhost.imvu.com", uhPort = 0, uhUserName = "", uhPasswd = ""}), urlPath = ["feed","feed-personal-10000","elements"], urlQuery = Nothing, urlHash = Nothing}),("elements",Url {urlHead = FullyQualified "http" (UrlHost {uhHostName = "api.localhost.imvu.com", uhPort = 0, uhUserName = "", uhPasswd = ""}), urlPath = ["feed","feed-personal-10000","elements"], urlQuery = Nothing, urlHash = Nothing})], eUpdates = Nothing}, eDenormalized = fromList [(Url {urlHead = FullyQualified "http" (UrlHost {uhHostName = "api.localhost.imvu.com", uhPort = 0, uhUserName = "", uhPasswd = ""}), urlPath = ["feed","feed-personal-10000","elements"], urlQuery = Nothing, urlHash = Nothing},EntityBody {eData = EntityCollection 0 (fromList []), eRelations = fromList [], eUpdates = Just (ImqUpdateMount (QueueName {qnType = "feed-personal", qnId = "10000"}) (Edge "elements"))})]}
It would be rather convenient to have an option to have the test output and the test execution itself on the same thread.
Activity
UnkindPartition commentedon Mar 20, 2015
I don't know of a way to do this which wouldn't increase the code complexity significantly.
sol commentedon Mar 20, 2015
Hspec runs all tests that are not explicitly marked for parallel execution on the main thread, exactly for that reason.
But it's true that this very requirement increases code complexity quite a bit.
Sent from my iPhone
UnkindPartition commentedon Mar 20, 2015
Tasty's architecture makes running independent from reporting — both logically and in terms of threads.
This allows to plug different (and even multiple) reporters easily, but this particular request it makes hard to accomodate.
The situation can be improved somewhat by enabling buffering (#101 (comment)). The output wouldn't be interleaved like it is right now, but it still wouldn't be synchronized.