Repository navigation
Spec #11
Description
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
Activity
rm-code commentedon May 13, 2017
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
bustedandluacheck.pablomayobre commentedon May 13, 2017
Yeah, that sounds good, you may have more experience with
bustedthough so I guess I'll leave that part to you.I have worked in the linter-luacheck package which uses
apm testfor testing so I'll try to do something like that, the problem being the simulation ofautocomplete-plus, in order to get the right suggestions. That's the part I need to investigaterm-code commentedon May 19, 2017
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 commentedon May 19, 2017
They do clone Atom similar to how Linter does it using the atom/ci scripts. Install their dependencies and call
apm testBut 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-luaand see if we get the whole list of functions (testing for modules, callbacks, functions and named types directly in the object). Trusting thatatom-autocomplete-luawill handle the rest right.Does that make sense? I can write the spec file if you want