[Feedhenry-raincatcher] Placement of client, server, mocks, stubs, fixtures in raincatcher modules

[Summers Pittman]

JIRA'd : https://issues.jboss.org/browse/RAINCATCH-559

On Fri, Feb 10, 2017 at 9:05 AM, Wojciech Trocki <wtrocki at redhat.com> wrote:

> I'm pro having tests in different directory as this would reduce number of
> files we would see and simplify browserify tasks. I'm not sure what's the
> reason behind using -spec suffix, so happy to find agreement on that
> matter.
>
> Wojciech Trocki
> Red Hat Mobile
>
> On Fri, Feb 10, 2017 at 1:26 PM, Emilio Rodriguez Martinez <
> emrodrig at redhat.com> wrote:
>
>> I guess the conclusion is the test directory was the old approach. Now we
>> should focus in the -spec suffix. +1 to the spec. I think the epic story
>> should be updated to sync our unit testing efforts during these sprints
>>
>> On Thu, Feb 9, 2017 at 9:49 PM, Peter Darrow <pdarrow at redhat.com> wrote:
>>
>>> So what's the conclusion here? Test files alongside code with -spec
>>> suffix, test files in a `test` directory, or test files in a `spec`
>>> directory? Since we're essentially rolling our own framework for
>>> RainCatcher modules, we should probably build a spec that defines exactly
>>> how modules should be laid out and then create a few JIRA issues to ensure
>>> we adhere to that spec everywhere.
>>>
>>> On Thu, Feb 9, 2017 at 11:36 AM, Paolo Haji <phaji at redhat.com> wrote:
>>>
>>>> I'm wondering why these files tend to be put together in the same
>>>>>>>>> directory? This has been a point of confusion when trying to understand the
>>>>>>>>> modules.
>>>>>>>>> For example, the user-client.js & user-router.js files in
>>>>>>>>> https://github.com/feedhenry-raincatcher/raincatcher-user
>>>>>>>>> /tree/master/lib/user are intended for the browser and node.js
>>>>>>>>> respectively.
>>>>>>>>>
>>>>>>>>
>>>> On this point raincatcher-user is probably the module in worst shape in
>>>> terms of clear separation.
>>>> For instance router/cloud.js is the cloud app part and router/mbaas.js
>>>> is the auth service part... This is mostly because the auth service is
>>>> handling all CRUD operations for the user data, as opposed to just handling
>>>> auth and leaving the profile data in the cloud app, so there's a lot of
>>>> calling through fh-mbaas-api from the cloud app to forward the http calls.
>>>> So for this module specifically there's browser, node-cloud-app and
>>>> node-auth-service code mixed in.
>>>>
>>>> _______________________________________________
>>>> Feedhenry-raincatcher mailing list
>>>> Feedhenry-raincatcher at redhat.com
>>>> https://www.redhat.com/mailman/listinfo/feedhenry-raincatcher
>>>>
>>>>
>>>
>>> _______________________________________________
>>> Feedhenry-raincatcher mailing list
>>> Feedhenry-raincatcher at redhat.com
>>> https://www.redhat.com/mailman/listinfo/feedhenry-raincatcher
>>>
>>>
>>
>> _______________________________________________
>> Feedhenry-raincatcher mailing list
>> Feedhenry-raincatcher at redhat.com
>> https://www.redhat.com/mailman/listinfo/feedhenry-raincatcher
>>
>>
>
> _______________________________________________
> Feedhenry-raincatcher mailing list
> Feedhenry-raincatcher at redhat.com
> https://www.redhat.com/mailman/listinfo/feedhenry-raincatcher
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/feedhenry-raincatcher/attachments/20170210/cbde482e/attachment.htm>