Testing Suites

[IshaGupta18]

Currently, we are working with Mocha in our tests in this repo. However, I think we should chime in a couple of thoughts here regarding this.
We should do a comparison between Mocha, Jasmine, and Jest, the first 2 being used in different PL's repos, as far as I know.
https://medium.com/welldone-software/an-overview-of-javascript-testing-in-2019-264e19514d0a
https://stackshare.io/stackups/jasmine-vs-jest-vs-mocha
The above are a couple of posts which discuss the three.
Here are a couple of resources from @jywarren https://marcofranssen.nl/jasmine-vs-mocha/ and like he said, @Souravirus has switched to Mocha in plots2 (publiclab/plots2#2967 (comment))
So if we could discuss the pros and cons of the three, it would be pretty great! I am beginning to write tests in mocha, just for the sake of understanding it right now.
Also, I would love a suggestion on a testing framework for UI testing.
cc @jywarren @rexagod @namangupta01 @gauravano @Souravirus @IgorWilbert

[jywarren]

Great, thanks for this summary!!!

I found some great references search Gitter for mocha:

https://gitter.im/publiclab/publiclab?at=59359203cf9c13503c570db7

ananyo2012 Did you find which testing framework has a better support for API testing?
ryzokuken Both Jasmine and Mocha have pretty solid support for API testing, I think.
ryzokuken I'll need to confirm that though.
ryzokuken You can even mock APIs in Mocha, I've heard.
ryzokuken http://robdodson.me/mocking-requests-with-mocha-chai-and-sinon/
ananyo2012 Yes Mocha has good support for mocks and Stubs

matrixbot @matrixbot Jun 05 2017 13:16
ryzokuken Actually, native Mocha doesn't come with any mocking/stubbing library like Jasmine
ryzokuken this allows us to use Siphon, which is more powerful than what comes preloaded with Jasmine.

Also from one of these results, input from @ananyo2012 (Hi Ananyo!!!!):

I was reading this: http://stateofjs.com/2016/testing/ today
To decide on what testing framework we should use
Seems like Mocha and Jasmine are the 2 most used JavaScript testing frameworks
But I dont really want to go with numbers

And my thoughts on it were:

Hi! On testing setups, we generally consider a few things: a) is it easy for newcomers to set up, b) is it well documented and maintained (maybe jasmine less so these days, i'm hearing from you all?), c) can we have consistency across our projects so people's skills transfer when moving between, and maybe others. But these are not blocking concerns; they just need to be balanced with the benefits. So if we're just trying mocha because it seems interesting, maybe not worth it, but if for one of these reasons it's better than Jasmine, and the pros outweigh the cons, go for it! Also, to some degree, if you've put hours into mocha and switching would be a lot of work, that's a good thing to consider too. Thanks!!!

[rexagod]

As far as mocking support is concerned, along with ananyo's concerns, I'd say the we should give Jest a spin. It wasn't there back in 2012, or wasn't atleast popular so to say, but it's got everything, from headless support (below) to semantic expect and it APIs for the newer contributors.

I can go ahead in this direction, explaining the whats and hows and even integrate it into this lib, given @jywarren and @publiclab/soc decide to pursue this direction.

[IshaGupta18]

I am okay with it I think since I am just exploring the three. have just begun with Mocha, although to start my testing, I require to create a UI test first. So that's why I got a little curious as to which framework we should use. I have seen the example given by @rexagod and I think it's pretty good. @jywarren what do you think? Should we give jest a shot?

[IshaGupta18]

@rexagod I have a small doubt. I need to test my CsvParser functions first (before moving to View's functions), but to do so, I need a div element ie a mock of a div element, because when the function reaches this line:

simple-data-grapher/src/CsvParser.js

Line 43 in c1dda36

SimpleDataGrapher.elementIdSimpleDataGraphInstanceMap[this.elementId].view.continueViewManipulation();

, it automatically shifts to the View file, which will return an error, if a div element (with some id) is not present

simple-data-grapher/src/View.js

Lines 311 to 315 in c1dda36

	this.elementId = elementId;
	this.element = document.getElementById(elementId);
	if(this.element == null){
	throw "No element exist with this id";
	}

. What do you suggest be done here?

[rexagod]

var div = document.createElement('DIV');
div.setAttribute('id','xyz');
...
...
div.parentNode.removeChild(div);

Dynamically create, run tests on, and remove the div.

[IshaGupta18]

Create this where? Btw this is what is there in the index.html file:

simple-data-grapher/examples/index.html

Lines 15 to 21 in c1dda36

	<div id="first"></div>
	<div id="second"></div>
	<script src="../dist/PublicLab.Grapher.js"></script>
	<script>
	a = new SimpleDataGrapher("first");
	</script>

[rexagod]

Add and delete the div during the period of the test run. Create the div, when test is done with it, destroy it.

[IshaGupta18]

Could you please elaborate a little more, I am so sorry to ask so many questions, I am actually unable to understand the flow here?

[rexagod]

What exactly are you unable to understand?

[IshaGupta18]

Where to make this mock div, and then how to make it accessible to the CsvParser or View object, because what I am planning to do is, create an object in the test file, and use it to call different functions of the class, and check the value each function assigned to a parameter. Does that make sense?

…

On Tue, Jun 18, 2019, 11:51 AM Pranshu Srivastava ***@***.***> wrote: What exactly don't you understand? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#49?email_source=notifications&email_token=AJXHQZ7VHMPVVHP2TR3FY4TP3B5HXA5CNFSM4HYYNHU2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODX5KBAY#issuecomment-502964355>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AJXHQZZJPOLGVR2YB3QGEVLP3B5HXANCNFSM4HYYNHUQ> .

[rexagod]

SimpleDataGrapher.elementIdSimpleDataGraphInstanceMap[this.elementId].view.continueViewManipulation();

Just before this line, make a div using js (syntax above). Actually there's no need to destroy it just don't append it to the DOM. Refer to that div's id in your tests. That's it!

[ananyo2012]

Hey all. Nice to have mentioned. That was quite some time back I had that discussion with @ryzokuken on testing framework. Here is what I feel on choosing a testing framework

1. Should have good mocking libraries. Having written tests in multiple frameworks and languages I feel this one is a major thing to consider. We don't want to spend a lot of time to write a mock or a stub which also makes it difficult to maintain.
2. Unit tests should be fast. With time the number of tests increases and so the time taken to execute them. You don't want to wait a long time to have tests to pass.
3. Should have good documentation as @jywarren mentioned. With a bunch of testing frameworks out there it can be difficult to consider which one to choose to from with just the above 2 points. When in dilemma always choose the one which has good support and documentation.

[ryzokuken]

I use Jest (because I'm lazy) these days mostly, but both Chai and Mocha are nice testing libraries. Please feel free to hit me up if you need help/more context regarding any.

[Souravirus]

Hi everyone, I changed the tests in plots2 from Jasmine to Mocha because jasmine-rails was unable to test modern ES features. So, there was a need for another testing suite and Mocha seems perfect at that time.

[jywarren]

Hi, this is not the same thing but a related convo on build tools was here - just found it: publiclab/PublicLab.Editor#227

[rexagod]

I was curious to know @publiclab/soc @publiclab/reviewers opinions on using npm scripts as the ultimate task runner, just to keep things simple and way more flexible, while considerably reducing the bug count (no third-party mirrors of deps). I guess we can consider integrating the newer modules with gulp or webpack or even grunt if people see advantages in the same, otherwise, maybe we should consider the former as well?

[jywarren]

I'm ok with npm as the task runner!

…

On Fri, Jun 21, 2019 at 5:32 PM Pranshu Srivastava ***@***.***> wrote: I was curious to know @publiclab/soc <https://github.com/orgs/publiclab/teams/soc> @publiclab/reviewers <https://github.com/orgs/publiclab/teams/reviewers> opinions on using npm scripts as the ultimate task runner, just to keep things simple and way more flexible, while considerably reducing the bug count (no third-party mirrors of deps). I guess we can consider integrating the newer modules with gulp or webpack for a change if people see advantages in the same, otherwise, maybe we should consider the former as well? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#49?email_source=notifications&email_token=AAAF6JZIJIAV2FVXOZ7XAKTP3VCF7A5CNFSM4HYYNHU2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODYJUKVQ#issuecomment-504579414>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAAF6JZ3CMU5W5UPI3MEVZ3P3VCF7ANCNFSM4HYYNHUQ> .

[IshaGupta18]

Any suggestions for UI testing with mocha @jywarren @namangupta01 @rexagod ?