Unit testing and CI (continuous integration) about appinspector HOT 16 CLOSED

I'd love to add testing.

If @bryntum is willing to sponsor a Siesta license, that would be amazing! @matsbryntse
Or we can use https://github.com/bryntum/fiesta!?

from appinspector.

Oh, Festa seems also great. :)

from appinspector.

@kawanoshinobu Hey, thanks for the good words about Siesta (I'm one of the developers)! Siesta Lite is free and can be used in any kind of project. We also offer good discounts on full license if someone wants to write a blog post about his experience with Siesta.

As about Fiesta - its main idea was crowd-sourcing of the test suites for open-source projects, probably not suitable for the proprietary code. Tests were supposed to be copied from Fiesta to project repository.

from appinspector.

I'm generally okay with the plan to have unit tests (whether in Jasmine, Siesta, etc), though I think having UI testing of any kind is going to be futile due to the fact we'll have to mock all of the chrome.* APIs and the individual responses. Just my $0.02 there.

Specifically I think unit test coverage (using Siesta) is a great idea for the AI.util classes - which all get run in the context of the inspected window.

from appinspector.

And yes, we wouldn't want (or be able) to use the full Siesta paid license because it would give away their source code for CI integration.

We could run Siesta Lite manually before releases, which I'm not opposed to.

from appinspector.

@samuraijack,

Thank you for the comment! I'm relieved to hear that we can use Siesta Lite for this project. Discount plan on full license is excellent. I will contact you at a later date. :)

@arthurakay,

I attempted to integrate Siesta Lite to AppInspector but am into stuck.. I keep trying.

By the way, I want to know how do you debug AppInspector with Chrome DevTools. If it doesn't bother you, please tell me how to do it, or good resource to learn it. 🙇 🙇

from appinspector.

Using DevTools to debug our DevTools extension is difficult in that I rarely get any useful information out of it. It frequently crashes that way.

I actually find it easier to run App Inspector on a localhost (like any other Ext app) and debug that way, though I've had to mock the chrome.* APIs in order to avoid error messages. I probably need to add those mocks in a block... I'll create a ticket for that.

But as I said, Siesta's UI testing is only going to be so useful for us. The best feature of Siesta is the sandboxing, so we could run the logical unit tests against ST2, Ext4 and Ext5 for our injected AI.util code.

I'm pretty familiar with Siesta, I can try to get that in place if you'd like.

from appinspector.

Of course I welcome you make it! I know you have excellent knowledge about Siesta and Testing. I am a big fan of your article about Sencha technology. :)

Now I understand it's a difficult matter to debug it. To run AppInspector as an ordinary app is a nice idea! I will try it. And If we had mock for it is great. Thank you for creating the ticket 😃

from appinspector.

I've got a lot more work to do on this, but the first pieces are in place. You can run the Siesta Lite suite by running ~/app/test/index.html on your localhost... but the host URLs I'm using as test pages are specific to my machine right now. I'll clean that up as I get the tests physically working, but you'll be able to see what I've done.

from appinspector.

Thank you for the implementation quickly!

I've seen your changes and I could understand how behaves the sandboxing feature of Siesta. I felt it is useful if we upgrade the library. I appreciate the commits that easy to understand the changes.

I think the test code is very helpful for new contributor that understands the spec of AppInspector. I'm really looking forward to run the test code on my local PC.

from appinspector.

Hi! I ran tests on my local PC. (As you placed SDK's, I also placed it.)

Excellent work! I've understood that you want to do.

Although you have the remaining work, may I add new test cases?

from appinspector.

You can... but I can't guarantee I'll accept them :-)

I'd like to limit any testing to the functions contained in the AI.util.* classes, specifically the ones run inside the inspected window. I really want to avoid going down the rabbit hole with tests, considering we probably aren't going to have these automated and I don't particularly want to be responsible for maintaining the tests. We should only focus on tests that are critical.

I will put together a README on what is currently in here and instructions to get this running so that we all have the same setup. This is a good exercise and I'm glad we're doing this, but I'm obviously hesitant to spend much time here. I've been scarred from previous experiences...

from appinspector.

"We should only focus on tests that are critical",, I agree with it. If I want to create the test, will consider it is really necessary or not.

I read the README.md and appreciate the good introduction. I have a suggestion, we use a connect web server to run the tests? I'm a little bit concerned to set up a specific rules web server for everyone who want to run it.

I added the grunt task to run the tests on Siesta. If you like it, please merge the pull request.

from appinspector.

Yes, I would agree on avoiding specific rules for a localhost setup and using connect/Cmd to launch that instead makes more sense.

As I mentioned in the merge conversation, I may explore using symlinks now that I'm seeing a few more oddities in the folder paths. Stay tuned on that.

from appinspector.

I updated the test README. Your changes work well!

I am going to close this ticket since there's nothing specific left in terms of a deliverable. If other tests or edits are needed, perhaps open a new ticket to discuss.

from appinspector.

I'm really happy to hear your message, and thank you for merged my pull request. :)
I want to do whatever I can help this project. Keep in Touch!

from appinspector.