<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Nov 28, 2013 at 3:26 PM, Daniel Narvaez <span dir="ltr"><<a href="mailto:dwnarvaez@gmail.com" target="_blank">dwnarvaez@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div id=":1j8" style="overflow:hidden">Those are hard questions :) I was also thinking about compatibility with old sugar-toolkit-gtk3 versions when we change stuff like getEnvironment.</div>
</blockquote><div>For future changes on this, we add some unitttest, so refactoring should be safer</div><div><a href="https://github.com/sugarlabs/sugar-web/pull/94">https://github.com/sugarlabs/sugar-web/pull/94</a><br>
</div><div><br></div><div>Please, can anyone review this pull-request??</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div id=":1j8" style="overflow:hidden"><div><br></div><div>What about having two configurations, one for Sugar running only inside sugar-build (what we have now), the other running into a normal web browser running outside sugar-build. Seems like this would ensure functionality of the contracts we currently care about? The sugar-web inside sugar-build would break if sugar-toolkit-gtk3 doesn't fulfil the the contract.</div>
</div></blockquote><div>This is a good idea, but I'm not sure if it's priority right now... perhaps in the short term this would bring-up again and we may revisit this issue.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div id=":1j8" style="overflow:hidden">
<div><br></div><div>There is a difference between testing that getEnvironment works or that the bits getEnvironment depend on (window.sugar) works as expected. Perhaps where we think that difference might matter we could also have tests which tests only the contract with toolkit, without other code layers in the middle. But getEnvironment is so thin that it probably doesn't matter at the moment..</div>
</div></blockquote><div><br></div><div>+1 </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div id=":1j8" style="overflow:hidden">

<div><br></div><div>We would need to figure out how to automate tests in a normal web browser, but shouldn't be much of a problem.</div></div></blockquote><div>Roger, pointed me out that datastoreSpec mainly fails on standalone mode... perhaps we should review those tests to find out if they can be fixed. But it's not enough for having two configs, yet, IMHO.</div>
<div><br></div><div>PS: we would like to rework a bit env.js, but we need the new unit tests merged in order to continue. If someone can review them soon will be appreciated.</div></div></div></div>