Spec

[pablomayobre]

I think that this package could have a good spec. Even though it's pretty simple, testing could be leveraged to a CI to make sure that nothing breaks from a release to the next. This would help to reduce problems in future PRs, when changing the version of love-atom or when a change in atom-autocomplete-lua breaks something.

The test would run with apm test, would install atom-autocomplete-lua and love-atom and then would get the suggestions from atom-autocomplete-lua somehow. I'll explore this stuff and gather the info here.

Testing is currently kinda awkward since you need to disable the real love-atom and install the fork as a development package, I would love to be able to push commits and see if they build in a CI service

[rm-code]

I actually had this in mind too, but I'm not familiar with testing frameworks for javascript.

The travis builds could also make sure the generator is working correctly via busted and luacheck.

[pablomayobre]

Yeah, that sounds good, you may have more experience with busted though so I guess I'll leave that part to you.

I have worked in the linter-luacheck package which uses apm test for testing so I'll try to do something like that, the problem being the simulation of autocomplete-plus, in order to get the right suggestions. That's the part I need to investigate

[rm-code]

Did you check some of the standard autocomplete provider packages?

Is it possible that they clone Atom itself in the travis build and then use some internal spec system?

[pablomayobre]

They do clone Atom similar to how Linter does it using the atom/ci scripts. Install their dependencies and call apm test

But no package tests if the suggestions are right, they check that their view and commands are in place and destroyed when they aren't needed anymore. Which is not something this package needs.

Instead I propose that we call the function that would normally be called by atom-autocomplete-lua and see if we get the whole list of functions (testing for modules, callbacks, functions and named types directly in the object). Trusting that atom-autocomplete-lua will handle the rest right.

Does that make sense? I can write the spec file if you want