It seems that the Water IDE does not yet support running tests via Ctrl+T the way that Fire does. Any ETA on this feature? And is there a straightforward way to run EUnit tests until the feature is added to Water?
Hmm, it should. what fails?
you should be able to just regularly “run” the test project as if it were a normal project. You won’t get the automatic capture of results as messages, but you’ll see the results ion the output pane…
Quite possibly my knowledge of testing in Elements 
In order to run EUnit tests, do I have to set up a separate “Test” project? I was assuming I could run my TestClass tests from directly within my normal project, the way for example Android Studio allows me to right-click a file and run tests.
The “Test” menu item is greyed out, which I assumed meant “not yet implemented,” but it sounds like that may just be a “Test Project” feature?
Check out https://blogs.remobjects.com/2016/05/30/elements-8-4-integrated-e-unit-testing-in-fire/.
Yes, the idea is you have a Test project, created with one of the EUNit templates, next to your main project; if you do, the Test option becomes enabled and it will run your test project instead of the “real” one and capture the test results. This should work in Fire and Water the same, afaik.
Thanks for the link - I was looking for something along those lines.
It still doesn’t seem to be working for me though. I tired adding a “EUnit Test Application (Android)” project to my existing project and still cannot run tests.
I then tried closing the solution and creating a new project from the Water splash screen. Again, a “EUnit Test Application (Android)” project. Then added New File > EUnit > Test Class but still testing does not seem to be enabled. I tried it with EUnit Test Application (Java) and got the same results.
Hmm, ok. I’ll need to have a look on Monday.
1 Like
Thanks, logged as bugs://81766
1 Like
<MenuItem Header="Test" InputGestureText="Ctrl+T" IsEnabled="False"/>
<MenuItem Header="Test all Projects" InputGestureText="Ctrl+Shift+T" IsEnabled="False"/>
oops 
1 Like
gotta love easy fixes at least
Fixed (yay for cross-platform code sharing; I literally just had to hook up the menus too the existing code <g>);
the basics work, but it there does still seem to be an (unrelated0 problem with it actually capturing the test results, which seems to be broken EUnit side (it doesn’t emit them in the proper form), not in Water. I’ll need to research that more, Monday.
1 Like
Fixed too, along with some other nice tweaks for hoe test messages are handled in the debug console. I can probably send you a new Water build tomorow.
1 Like
Excellent, thanks!
Up now.
Note that there is one more outstanding bug in the debug engine itself (ie not my code) where on some target platforms it might not pass the right environment variable to the debugger in order to enable special output of EUnit messages in a way that Fire/Water can pick them up and highlight them. I’m not sure if that affects the platform(s) you’re targeting, but thats loved to be fixed for next week (the tests will still run, you just might niot get the IDE integration where they show as “Messages” inline in the editor.
1 Like
Thanks Marc, tests are running on this build.
To run tests in my existing Android app project, I added an EUnit test project inside the solution. How do I access namespaces from my main project from within the test project? Do I need to move my project files into a shared project?
1 Like
shared project, a plain library that both use or, in the case of java, i be,i eve you can even just reference the main project from the test app, as all java projects compile to a .jar that can be used as an dynamic library…
1 Like
(Not sure if Water will let to drag a project reference; it might be trying to be “too smart” for it’s own good, know that it’s a non-library project (though on binary level there’s no diff) and disallow it. If thats the case, late the .jar file (it won’t be in Bin, it’ll be somewhere in /obj, but the build log will have the name & path), and add a regular file-based reference, as you would to a standard .jar library you have n disk, by just dragging the file from Finder onto your test project’s References node)
Update: turns out, Water lets you’d the ref, but EBuild doesn’t like it. Will fix, but for now, use the .jar ref.
I just finished doing exactly that, and it works great!
One thing I noticed is that I had a .jar in my project /bin folder but it was several weeks old. The latest was in %AppData/RemObjects Software/.../obj folder. The jar in my /bin was from about the time that I moved from Elements 9.3 to 10 and also moved from VS to Water. Did one of these change the location my jar is produced? If so, is there a way to change that setting? I’d rather it be output in the project folder since then it’s grabbed in my VCS syncs with all my project files. Otherwise the jar remains buried in my local AppData folder.
Excellent. Project refs will work in vNext.
Yep. the old build chain always copied the .jar to bin, even though when building a .apk, it’s really just an intermediate output file that you don’t wanna deploy. EBuild fixed that, and only copies there .apk (but it cannot clean up files it doesn’t; technically know about, so the old .jar would have remained left over.
Right now, the /obj stuff always goes to AppData (the /obj folder isn your project is also just an outdated leftover from MSBuild). these files should not be commuted into version control (same goes for MSBuild’s /obj), and should be considered local, machine specific temp files. they can also be huge, as especially for Android, a lot of intermediate work happens and a lot of files get dumped in /obj. These files should be considered opaque and only relevant to the internal workings of the build chain for speeding up your build.
All you should care about is what’s in your project, and what gets copied to the specified Output folder (ie Bin\Debug).
1 Like
this is all good now, right?
1 Like
bugs://81766 got closed with status fixed.