<html><body>
<p><font size="2" face="sans-serif">Love the idea, great explanation! I see value in this going forward. Definitely interested.</font><br>
<br>
<img width="16" height="16" src="cid:1__=07BBF41BDFF343EB8f9e8a93df938@us.ibm.com" border="0" alt="Inactive hide details for "Chen, Shaoquan" ---07/19/2015 05:34:42 PM---Currently random mock objects are created inside of spec"><font size="2" color="#424282" face="sans-serif">"Chen, Shaoquan" ---07/19/2015 05:34:42 PM---Currently random mock objects are created inside of spec files to make writing unit tests easier. Th</font><br>
<br>
<font size="1" color="#5F5F5F" face="sans-serif">From: </font><font size="1" face="sans-serif">"Chen, Shaoquan" <sean.chen2@hp.com></font><br>
<font size="1" color="#5F5F5F" face="sans-serif">To: </font><font size="1" face="sans-serif">"OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org></font><br>
<font size="1" color="#5F5F5F" face="sans-serif">Date: </font><font size="1" face="sans-serif">07/19/2015 05:34 PM</font><br>
<font size="1" color="#5F5F5F" face="sans-serif">Subject: </font><font size="1" face="sans-serif">[openstack-dev] [Openstack][Horizon] Sharable Angular mock</font><br>
<hr width="100%" size="2" align="left" noshade style="color:#8091A5; "><br>
<br>
<br>
<tt><font size="2">Currently random mock objects are created inside of spec files to make writing unit tests easier. This approach works but has some drawback:<br>
<br>
* mocks are not sharable between specs.<br>
* mocks are usually too simple.<br>
* mocks may not be consistent between spec files.<br>
* mocks are not tested theme self.<br>
* hard to maintain and manage.<br>
<br>
In order to make it easy for developers to write high quality unit tests and e2e test, we want a set of high-quality mock objects. To make its easy to maintain:<br>
<br>
* mocks should reside in ``.mock.js`` files and be loaded only in test runner page<br>
* mocks should be loaded after production code files, before spec code files.<br>
* mocks should be sharable between specs.<br>
* mocks are not belong to specs, they should have a 1:1 relationship with the object it try to mock.<br>
* mocks should be at a level as low as possible, maybe where JavaScript cannot reach directly.<br>
* mocks must be tested theme self.<br>
* mocks should be easy to find, use and manage.<br>
<br>
I drafted a simple BP at </font></tt><tt><font size="2"><a href="https://blueprints.launchpad.net/horizon/+spec/horizon-angular-mocks">https://blueprints.launchpad.net/horizon/+spec/horizon-angular-mocks</a></font></tt><tt><font size="2"> to summaries the issue existing in Horizon IMO and how I could see to fix them. I also setup two patches to prove the concept at:<br>
<br>
* </font></tt><tt><font size="2"><a href="https://review.openstack.org/#/c/202817/">https://review.openstack.org/#/c/202817/</a></font></tt><tt><font size="2"><br>
* </font></tt><tt><font size="2"><a href="https://review.openstack.org/#/c/202830/">https://review.openstack.org/#/c/202830/</a></font></tt><tt><font size="2"><br>
<br>
This mock is for the window object and another could be OpenStackHtttpBackend which mimic all the behaviors of Horizon Web services. As you can see, the window mock object can be easily applied to a bug Tyr fixed recently so that the spec code do not need to create an inline mock object. Because those shared mock are independent from specs, they can be more neutral and can have much more features than a over simplified mock for a specific test.<br>
<br>
Please let me know if this interested you.<br>
<br>
Thanks,<br>
Sean<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<br>
</font></tt><tt><font size="2"><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a></font></tt><tt><font size="2"><br>
<br>
</font></tt><br>
</body></html>