[almighty] Test "classes"

[Pavol Pitonak]

Hi,

this is in line with what I would suggest. In Red Hat we usually refer to
these "classes" as tiers.

For actual tools that you might use, I would suggest to start with whatever
is most popular in Node.js/JavaScript community. You will get a lot of
documentation for best practices and troubleshooting.

For unit tests, have a look on Mocha (mochajs.org) and Jasmine (
jasmine.github.io). The main difference is that Jasmine is all-in-one
solution while Mocha is only test runner. You need an assertion library
(e.g. chai) and library for creating fakes (spies, stubs and mocks) such as
Sinon. Mocha+Chai+Sinon is much more powerful but Jasmine is sufficient in
99.9% of cases and forces you to create your tests in one way.

For functional tests, I would go for Karma. Most people seem to use it with
Jasmine but it's possible to use it also with Mocha.

For e2e tests, Protractor seems to be the best place to start. It uses
WebDriver/Selenium in the background.

Whatever stack you choose, keep the code style (assertions etc.) consistent.

On Tue, Sep 20, 2016 at 5:13 PM, Leonard Dimaggio <ldimaggi at redhat.com>
wrote:

> Good discussion Michael! See comment below:
>
> On Tue, Sep 20, 2016 at 8:53 AM, Michael Kleinhenz <kleinhenz at redhat.com>
> wrote:
>
>> Hi,
>>
>> just to start some discussion. I would divide tests for the ui into
>> three classes:
>>
>> 1. Unit Tests
>> -> ususal stuff, testing internal wiring and payload code.
>>
>> 2. Functional Tests
>> -> tests of the ui behaviour, like "when I add a workitem using the
>> form, does it appear in the listview?". For this tests, I would go for
>> a full mocking of external services and use something native to keep
>> dependencies footprint small.
>>
>> 3. Smoke (or E2E) Tests
>> -> tests the full setup, starts all services, cases go full stack. For
>> this, we'll need a powerful test framework that can cover full stack.
>>
> *------> I'd also like to see us be able to verify faily complex,
> multi-step scenarios in these tests.  *Glad to see that you refer to
> these as E2E tests and not just smoke tests.
>
>>
>> For responsibility (or location), I'll see 1 and 2 go into the
>> respective repository. For 3, I'll would see that as a seperate thing,
>> *maybe* even a seperate repository.
>>
>> Any thoughts?
>>
>> -- Michael
>>
>> --
>> Michael Kleinhenz
>> Principal Software Engineer
>>
>> Red Hat Deutschland GmbH
>> Werner-von-Siemens-Ring 14
>> 85630 Grasbrunn
>> Germany
>>
>> RED HAT | TRIED. TESTED. TRUSTED.
>> Red Hat GmbH, www.de.redhat.com,
>> Registered seat: Grasbrunn, Commercial register: Amtsgericht München,
>> HRB 153243,
>> Managing Directors: Paul Argiry, Charles Cachera, Michael Cunningham,
>> Michael O'Neill
>>
>> _______________________________________________
>> almighty-public mailing list
>> almighty-public at redhat.com
>> https://www.redhat.com/mailman/listinfo/almighty-public
>>
>
>
>
> --
> Len DiMaggio (ldimaggi at redhat.com)
> JBoss by Red Hat
> 314 Littleton Road
> Westford, MA 01886  USA
> tel:  978.392.3179
> cell: 781.472.9912
> http://www.redhat.com
> http://community.jboss.org/people/ldimaggio
>
>
>
> _______________________________________________
> almighty-public mailing list
> almighty-public at redhat.com
> https://www.redhat.com/mailman/listinfo/almighty-public
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/almighty-public/attachments/20160921/422585be/attachment.htm>