Best way to write a 'continuous testing' plugin?
I'd like to write an IntelliJ plugin that facilitates continuous testing. Not so much for serious development, yet, as much as to make it fun to practice coders dojo katas (http://content.codersdojo.org/home/).
As things stand, Infinitest will automatically run tests as soon as you make your project (for instance with Ctrl+F9).
I'd like to find a way to avoid having to do anything other than actually writing your code.
My first idea was to attach a listen to document save events, since I knew that IDEA automatically saves your files. Unfortunately this was not a good option as it is only invoked rarely, and usually due to user action.
My second idea was to spawn a thread that would sit there regularly attempting to run 'make' on the project - for instance every 5 seconds.
This got me much closer to my goal, but raised some issues.
- IDEA doesn't like unauthorised threads accessing the CompilerManager and calling .make()
- When there are issues with the .make() call, a panel is liable to pop up and steal focus from the editor
- If the .make() fails due to syntax errors which can be seen from IDEAs usual inspections, it would be better not to report or to have tried the .make()
Can anyone offer any advice as to either a better approach, or solutions to these problems?
Thanks very much!
Please sign in to leave a comment.
For anyone interested, here's a progress report in terms of me figuring out options for myself.
I've found a lot of interesting Topics I can listen to on the message bus. These should give me hooks for deciding when to actual execute a compilation/test cycle. I've included what I've found at the end of this message.
Most interesting, though, is AnActionListener. It covers all kinds of editor actions, all of which you can listen to. So my current plan is to find a set of actions that indicate the code has probably been changed, and subsequently invoke '.make(project)'. For an interesting set of actions, have a look at com.intellij.openapi.actionSystem.IdeActions.*.
That just leaves:
Investigation continues.
List of found topics ("Find usages" of Topic interface in Community code-base):
UpdatedFilesListener
ChangeListener (shelf updates)
Notification (branch mapping changed)
DetailedNotification (ditto)
CommittedChangesReloadListener
Runnable (remote version changed)
LocalChangeListsLoadedListener
VcsListener
Runnable (usage view rules changed)
SvnMergeInfoCacheListener
ProjectSaved
DocumentBulkUpdateListener
BatchUpdateListener
AppLifecycleListener
EditorHintListener
StatusBarInfo
VirtualFilePointerListener
BulkFileListener
ProjectLifecycleListener
DumbModeListener
FileEditorManagerListener
Listener (storage listener)
Notifications (?)
FileTypeListener
FileDocumentManagerListener
ProjectManagerListener
AnyPsiChangeListener
PsiDocumentTransactionListener
NavBarModelListener
BookmarksListener
Listener (power save mode listener)
RunContentWithExecutorListener
PropertyChangeListener (Index patterns)
Listener (project jdk table)
FindModelListener
FacetManagerListener
ExecutionListener (configuration executed)
DaemonListener (daemon event topic)
ProjectTopics.ModuleRootListener
ProjectTopics.ModuleListener
ProjectTopics.LogicalRootsManager.LogicalRootListener
PsiModificationTracker.Listener
ConfigurationErrors
ArtifactListener
CompilationStatusListener
Hello Rajit,
I don't think there exists a perfect solution for these problems. make()
is a fairly heavy operation which somewhat interferes with the user's work
even if it doesn't pop up dialogs.
The easiest way to check files for syntax errors is to use the CodeSmelDetector
service. To avoid the threading assertions, you can pass the make() call
to the EDT using invokeLater().
--
Dmitry Jemerov
Development Lead
JetBrains, Inc.
http://www.jetbrains.com/
"Develop with Pleasure!"