Get help with testing, discuss unit testing strategies etc.


Post by klodoma »

I have the following questions open:

1. Watch mode

Is there a watch mode where the tests will be automatically re-executed during development?
Eg: if a source or test file changes on the disk.

Something like karma's watch mode.

2. Comparison to jasmine test-cases

I didn't dig deep into this, but what confused me now are the following:

What is the difference between or why should one use, advantages, disadvantages:
t.is vs t.expect(a).toEqual(b)? 
t.it vs t.describe?
... probably there are more, haven't checked 
3. Targeted code coverage
This is probably a tough one due to the nature of javascript.

Normally, one test targets the functionality of one or more functions.
Is there a way to limit the code coverage to taken into account ONLY by these tests and ignore the rest of the calls?

I could detail this separately if required.

I am looking for something similar to @covers from phpunit tests(PHP specific)
https://phpunit.readthedocs.io/en/8.1/annotations.html?highlight=covers#covers

Thanks!

Post by nickolay »

Hi,

Answering your questions:
klodoma wrote: Mon Jun 03, 2019 9:08 am 1. Watch mode

Is there a watch mode where the tests will be automatically re-executed during development?
Eg: if a source or test file changes on the disk.

Something like karma's watch mode.
Unfortunately, there's no such feature. It can be emulated using regular command line facilities though: https://eradman.com/entrproject/
klodoma wrote: Mon Jun 03, 2019 9:08 am 2. Comparison to jasmine test-cases

I didn't dig deep into this, but what confused me now are the following:

What is the difference between or why should one use, advantages, disadvantages:
t.is vs t.expect(a).toEqual(b)? 
t.it vs t.describe?
... probably there are more, haven't checked 
There's no much difference between the `t.is()` and `t.expect().toEqual()`. The former allows you to specify the description for the assertion, the latter does not. You can pick the assertions style you are most comfortable with.
Regarding `t.it()` and `t.describe()` - there's no much difference either. Historically (coming from Jasmine I guess), the test suite is organized as several top-level "describes", which contains several "its". However, both just creates Siesta's [subtest](https://www.bryntum.com/docs/siesta/#!/api/Siesta.Test-method-subTest). Subtests are organized as tree, thats all. Subtests are also created by some other methods, like [snooze](https://www.bryntum.com/docs/siesta/#!/api/Siesta.Test-method-snooze) and [todo](https://www.bryntum.com/docs/siesta/#!/api/Siesta.Test-method-todo)
klodoma wrote: Mon Jun 03, 2019 9:08 am 3. Targeted code coverage
This is probably a tough one due to the nature of javascript.

Normally, one test targets the functionality of one or more functions.
Is there a way to limit the code coverage to taken into account ONLY by these tests and ignore the rest of the calls?

I could detail this separately if required.

I am looking for something similar to @covers from phpunit tests(PHP specific)
https://phpunit.readthedocs.io/en/8.1/annotations.html?highlight=covers#covers

Thanks!
Looking on the phpunit docs, no this feature is not supported. The code coverage information in JavaScript only includes the source file and line number and does not include the reflection information, like to which class & method this line belongs.

Post by klodoma »

Thanks for the responses!

Post Reply