<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">This though comes from the rules applied in my dev team : one of those rules specifies a pretty strict formatting of unit tests, with the three different parts, separated by an empty line : setup, execute (most often one single line for unit tests, highlighted by an "// Execution" comment) and validation. The validation part regroups asserts, and can mix validation on a thrown error and on the status of an object.</div><div class="">This requires that the thrown error is stored in a variable at execution time, to be accessible at validation time.</div><div class="">This strict and consistent formatting across tests is very pleasant : it makes it easy to read tests, and analyse failures. It is a time gain when tests go red :-).</div><div class=""><br class=""></div><div class="">But I understand that this is a local development rule, and such rules are very different between teams.</div><div class="">Maybe having both possibilities (the error handling bloc and the return variable) would be ideal : it would fit all situations.</div><div class=""><br class=""></div><div class="">Jérôme</div><br class=""><div><blockquote type="cite" class=""><div class="">Le 14 janv. 2016 à 20:34, Mike Ferris <<a href="mailto:mferris@apple.com" class="">mferris@apple.com</a>> a écrit :</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Do you think that approach has a specific advantage over the current approach where the thrown error is passed into the optional block parameter?<div class=""><br class=""></div><div class="">They seem more or less equal in what they allow you to accomplish and I kind of like the scoping of the code to check the error within the block associated with the assert that catches the throw…</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">Mike</div><div class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Jan 14, 2016, at 11:31 AM, Jérôme Duquennoy via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><br class=""></div><div class=""><blockquote type="cite" class=""><div class=""><span style="font-family: TimesNewRomanPSMT; font-size: 14px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">4. We’re<span class="Apple-converted-space"> </span></span><i class="" style="font-family: TimesNewRomanPSMT; font-size: 14px; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">not</i><span style="font-family: TimesNewRomanPSMT; font-size: 14px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class=""> going to add the ability for<span class="Apple-converted-space"> </span></span><font face="Menlo" class="" style="font-size: 14px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><span class="" style="font-size: 11px;">XCTAssertThrowsError</span></font><span style="font-family: TimesNewRomanPSMT; font-size: 14px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class=""><span class="Apple-converted-space"> </span>to check that a specific error was thrown. This could definitely be useful but would require the function to take an<span class="Apple-converted-space"> </span></span><font face="Menlo" class="" style="font-size: 14px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><span class="" style="font-size: 11px;">ErrorType</span></font><span style="font-family: TimesNewRomanPSMT; font-size: 14px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class=""><span class="Apple-converted-space"> </span>instance that also conforms to<span class="Apple-converted-space"> </span></span><font face="Menlo" class="" style="font-size: 14px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><span class="" style="font-size: 11px;">Equatable</span></font><span style="font-family: TimesNewRomanPSMT; font-size: 14px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">. We need to think about that some more before making such a change. Fortunately this sort of addition will be straightforward to put in via an overload or default argument, so if we choose to do it later, it shouldn’t break any code that starts to adopt<span class="Apple-converted-space"> </span></span><font face="Menlo" class="" style="font-size: 14px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><span class="" style="font-size: 11px;">XCTAssertThrowsError</span></font><span style="font-family: TimesNewRomanPSMT; font-size: 14px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">.</span></div></blockquote></div><br class=""><div class="">Wouldn't it be possible to have <span style="font-size: 11px; font-family: Menlo;" class="">XCTAssertThrowsError</span> return the thrown error, so that the dev can do it's own test (validating an error code for exemple) ?</div><div class="">This would be fairly easy to implement (see the code I proposed on the 11th), and very flexible (it allows any dev to validate whatever he wants in its custom error type).</div><div class=""><br class=""></div><div class="">Jérôme</div>
<img src="https://u2002410.ct.sendgrid.net/wf/open?upn=qCTjHmennvWckZUgqTp8Fd-2Fuh5ocG9KEhDc-2FQVY-2FS9BlfZMu-2F3vGc28nYP1YrB6W9hiWB-2F8cSuTqkP9lQlb5RCadIfOPkUVCTF8yzjUEKXMA4evBQvPNCZa-2BB6r-2FnqYgxIxhNRZSFEOzjAudSCNWy3uisSRWlZwJEoTRZOqGLK5FMJf5LOdIAUiA3E34j7X-2F4kiGYZguGpQcOt-2FV4y270nSkzHuTD0-2FEGGwOh-2BytfWk-3D" alt="" width="1" height="1" border="0" style="height:1px !important;width:1px !important;border-width:0 !important;margin-top:0 !important;margin-bottom:0 !important;margin-right:0 !important;margin-left:0 !important;padding-top:0 !important;padding-bottom:0 !important;padding-right:0 !important;padding-left:0 !important;" class="">
</div>
_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></blockquote></div><br class=""></div></div></div></blockquote></div><br class=""></body></html>