ciscoheat / buddy

Your friendly BDD testing library for Haxe!
MIT License
96 stars 24 forks source link

Working with HaxeFlixel projects #45

Closed IBwWG closed 8 years ago

IBwWG commented 8 years ago

I tried taking the default HaxeFlixel template and integrating buddy tests with it, but I need some help. I added the Main.hx from the buddy readme to my project's root, and it runs fine from the command line. I then added this test to it (at the beginning of the constructor):

describe("A 100x100 rectangle at the origin", {
    var rect = new FlxRect( 0, 0, 100, 100 );
    it("should contain the point 50, 50", {
        rect.containsPoint( new FlxPoint( 50, 50 ) );
    });
});

I made sure the correct libraries were imported for FlxRect and FlxPoint, and added -lib flixel to the command for running the tests. I then get this error:

...\buddyhftest>haxe -lib buddy -lib flixel -main Main --interp
C:\HaxeToolkit\haxe\lib\flixel/git/flixel/math/FlxPoint.hx:3: characters 7-23 :
You cannot access the flash package while targeting neko (for flash.geom.Point)
Main.hx:2: characters 7-27 :     referenced here

Does this limitation mean that buddy isn't currently usable with a HaxeFlixel project?

ciscoheat commented 8 years ago

Hello, I think the problem is that you're using --interp for executing the tests, which uses Neko. If you're using flash, you should do run them through the flash runtime, or through the command-line with the flash hxml script for example, though I have no idea how that works with HaxeFlixel. :)

IBwWG commented 8 years ago

Ah, I wondered what --interp did, but I hadn't suspected it was causing trouble for me. Thanks!

This is a bit beyond me at the moment. So far everything has been made perhaps overly simple using FlashDevelop and templates, so although I've dug around a bit I'm not certain how to run them through the flash runtime. I see the -D fdb-ci in the file you linked to, but I suppose that's meant for Travis (also the chmod line probably won't work on Windows.) I found a debug.hxml that is automatically generated when I compile the project normally, so I tried combining its contents with the flash hxml script you linked to variously, but I can't seem to come up with something that works.

That is to say, I can get it to compile, but it seems that when I do, it's just outputting the same swf as the main application (even though I'm pointing it at buddy's Main instead of the generated ApplicationMain) and running it in the flash debugger produces no test output (not even if I put some trace() calls in buddy's Main.hx)--just the same empty window the main application does.

IBwWG commented 8 years ago

Wait, I'm getting somewhere: while I was including the line -cp source it was still actually using my application's Main.hx. Now I get some Buddy output! However, my little test above just says "Pending". Hmm...I guess that's because I wrote my test badly, and it should have this at the end:

rect.containsPoint( new FlxPoint( 50, 50 ) ).should.be(true);

Hooray, it passes! For whatever reason, since making this change I suddenly have many lines like the following in FlashDevelop's output pane related to autocompletion:

C:\HaxeToolkit\haxe\std/haxe/ds/GenericStack.hx:67: lines 67-68 : Field new has no expression (possible typing order issue)
C:/HaxeToolkit/haxe/lib/hscript/2,0,5/hscript/Parser.hx:46: characters 0-5 : Defined in this class
C:/HaxeToolkit/haxe/lib/hscript/2,0,5/hscript/Parser.hx:92: characters 1-42 : While building haxe.ds.GenericStack_hscript_Token
C:/HaxeToolkit/haxe/lib/hscript/2,0,5/hscript/Parser.hx:46: characters 0-5 : Defined in this class
IBwWG commented 8 years ago

One other point of integration: Currently, I run from the command line haxe debug.hxml, which compiles an SWF with the test suite present. Then I double-click that SWF from within FlashDevelop, and it runs it while FD connects to the flash debug session. I see the Buddy output in the output pane of FlashDevelop. Afterwards the Flash debug player remains running and I have to manually close its window. I wonder if there's a way to get these three things into one step...then, hopefully, to do this for each target I want to support, so that I can just "launch all tests" and then do something else without having to be there to manually intervene.

ciscoheat commented 8 years ago

Glad you're making progress. :) I think the -D fdb-ci flag could help you with that actually. Sorry for the cryptic name. It makes flash exit after the tests are run, but to allow that you need to create a flash configuration file, and another file for making the directory trusted. See the end of flash-travis-setup.sh for how to do that.

That should take care of closing the window, and if you use FlashDevelop so you can see Buddy output there, maybe that's all you need for now?

IBwWG commented 8 years ago

Nice! ci makes sense, I just didn't think it would be for this particular detail. Thanks, I'll look into that and try to adapt it to Windows and see what we get!

I suppose...it would be nice to get rid of the autocomplete errors, but maybe I caused that by copying too many libs from my project's hxml file. I'll try without hscript...

IBwWG commented 8 years ago

OK, no hscript reference = no autocomplete errors, yet still compiling and testing fine. Check. :)

Also, it was a lot less confusing to rename Main.hx (and Main within it) to TestMain.hx (and TestMain) and put -main TestMain in my hxml file. That way I can have packages within my source directory and still include it without the haxeflixel project Main.hx being compiled instead of the buddy Main.hx.

Now for ci...

ciscoheat commented 8 years ago

Speaking about CI, have you looked at https://github.com/andyli/HaxeCI ? It's a great starting point for Travis and Appveyor integration. It would be very interesting to see if HaxeFlixel could be tested in that environment.

IBwWG commented 8 years ago

mm.cfg was already set up right--probably how FD taps into it. buddy.cfg I made using directories from Adobe's site:

 Windows: system\Macromed\Flash\FlashPlayerTrust

(for example, C:\WINDOWS\system32\Macromed\Flash\FlashPlayerTrust)

Mac: app support/Macromedia/FlashPlayerTrust

(for example, /Library/Application Support/Macromedia/FlashPlayerTrust)

Unfortunately, that doesn't quite seem to be right. It does make the Flash player disappear right away, but it's so fast that FD doesn't actually connect to it...its status bar says "Waiting for flash player..." a split-second after the player has already vanished. Meanwhile, where did the output go? Apparently that's hard-coded to C:\Users\username\AppData\Roaming\Macromedia\Flash Player\Logs\flashlog.txt, which it overwrites on each run. That's at least fixable with a batch file for the moment.

Next I'll have to see if I can get it working with cpp, which is something I haven't figured out how to do with haxeflixel and munit/mcover.

IBwWG commented 8 years ago

I hadn't looked at HaxeCI yet...thanks, I'll keep that in mind if/when I actually move to Travis. :)

ciscoheat commented 8 years ago

Sorry for all that trouble, Flash really isn't made for CI...! Let me know if you need any more help.

IBwWG commented 8 years ago

No worries, I hear you, and thanks for all the accommodations you made for it already. :) Also our conversation here helped me get munit/mcover working too, so now I can have the best of both worlds as needed.

I'm having trouble with cpp but I haven't dug quite far enough yet I think...I'll definitely take you up on the offer of more help if I can't figure it out!

ciscoheat commented 8 years ago

Hello, I've just released version 1.0.0, much more stable and with a few useful features like beforeAll afterAll. Please check it out. :)

IBwWG commented 8 years ago

Will do eventually, but I have another project for a bit. :) Thanks for letting me know!