It may take a bit to start.

Vanaria: Cork, so using Js to manipulate the svg won’t allow me to export those changes? or are you saying something else?

Lesslie: I am getting into QUnit for the first time. How should I do unit testing? Should I set up 2 different projects with 1 having unit testing and the other being the actual project?

Cena: For example if the plugin binds a click handler on the svg

Dehler: That js code that does does things on click might be hard to export

Huffines: But if the svg is just an image, exporting isn’t hard

Vanaria: Cork, oh ok. yeah won’t need any of that :

Vanaria: I’m attempting to generate like a coupon or even a small menu that allows me to add items to it, etc

Vanaria: I’m just so lost as to what the best method is

Mattila: Lesslie: one argument would be to have your qunit in your project, that way it is version controlled along with your proje ct

Lesslie: Mattila: that’s right.Also, I should keep it all together.the actual JS should contain the testing units.

Mattila: Uh, i dunno i would go that far

Lesslie: Mattila: so how is it suppose to be done?

Mattila: I mean you could, but if your doing any sort of project that compiles a release, your build could be made to exclude the tests from the production site

Mattila: No need for the users to see your tests

Lesslie: Mattila: you are right

Mattila: Things to think about, :

Lesslie: Mattila: Should I keep one separate JS with all the testing units and then just strip out the test units to create the public js file?

Mattila: Been a bit since i played with qunit, but i’m ***uming it’s similar to jasminejs. so in that aspect, what we usually do is have a src folder with out real code and a sibling folder tests with all the individual files with the tests for each related actual js code file

Mattila: The test page includes both the sources and test files

Mattila: Your build script could then ignore the test folder

Popkin: Hi, anyone familiar with jquery cycle?

Lesslie: Mattila: Mattila: So in TDD, I will write the test first on my tests/ folder. That test should then fail because there is no actual implementation of it. On my src/ folder, I create the actual code to be tested. Then the test should p*** if all is okay.

Lesslie: Mattila: How do I ***ert.ok on a synchronous callback function. For example, I want to ***ert that the callback was called. The only way that I can think of doing that is by having ***ert.oktrue, ‘yay’; inside of the function itself. But how would I do that if the tests are separate from the actual code?

Mattila: I would ***ume quint would have some manner of mocking function calls

Mattila: So your not actually making the call

Mattila: You can verify it would call it with the correct parameters, and then you could verify the separate callbacks

Lesslie: Mattila: right. I would have to add a Mocking plugin for QUnit:

Lesslie: Mattila: How do you automate testing units?

Mattila: Mocking is very nice, imho. it helps to keep your tests self contained

Lesslie: Mattila: in the case of QUnit

Mattila: I can’t speak for qunit. not intimately familiar with that testing toolsuite

Lesslie: Mattila: how about JasmineJS

Mattila: That i can give you an example of

Mattila: Https://

Mattila: And

Mattila: Bbs, i gotta go hit up a meeting

Lesslie: Mattila: Hey buddy, thanks for the info!

Lesslie: Mattila: it did help a lot actually!

Mattila: The root of that github project also has a link to a test staging site where you can see the live tests if you want

Mattila: It may take a bit to start as it’s a cloud site that may have to spin up