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: https://qunitjs.com/plugins/
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://github.com/Mattila/site-editor/tree/master/public/scripts
Mattila: And https://github.com/Mattila/site-editor/blob/master/tests.html
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