Skip to content

write tests in asset directory with testscript #5

Closed
zaceno opened this Issue Aug 31, 2013 · 6 comments

2 participants

@zaceno
zaceno commented Aug 31, 2013

Perhaps I'm not understanding this correctly ( I'm not clear on how to ask support questions on github...) but when I use the testscript, It seems I cant write tests in my assets directory, because they are run from the public directory.

Is this the expected behavior?

It makes sense, I guess, since, as the docs say, you don't want mimosa getting in the way when doing heavy test-coding -- and you'd need mimosa for compiling from the assets to public directory. But on the other hand, for the sake of mimosa you want to code in the assets directory because 'public' gets overwritten from there.

So I guess I'm just confused about how the testscript is supposed to be used.

Again, I apologize if this is not the right forum for this type of question. Kindly point me in the right direction if so.

@zaceno
zaceno commented Sep 1, 2013

Ok, I think I figured it out, maybe useful to someone else:

What you can do is run mimosa watch &, and after that ./test.sh -- that way you get the live compiling from your assets going, but the in-browser runner and regular testem reporter going at the same time.

I suggest the README could be clearer. I got the impression from them that mimosa and ./test should not be run simultaneously (thought maybe there would be two testems stepping on eachothers toes or something)

The chain-effect is pretty neat actually. Change my code, mimosa autocompiles it, testem notices changes in public dir, and live reloads the test-reporter in my browser.

@dbashford
Owner

First off, thanks for checking out Mimosa!

And thanks for sharing what you learned. I've updated the README and pointed it at this issue. I hope it clears things up a little. I definitely never meant to insinuate there is any issue running mimosa and the test script at the same time. This module is about two things, 1) setting up your config for you (and it can get complicated and a pain to maintain) and 2) running it in a regression/ci fashion to make sure as you make changes that you aren't breaking tests. But once you switch contexts and go into test creation or complex test debugging, unfortunately because testem ci does not allow console.logs, its hard to debug in mimosa watch. That's why the test script is necessary: to allow you to use and invoke all the config that Mimosa sets up without needing to figure out the command to do it.

I'm happy it all worked out for you, and its pretty damn cool that testem and mimosa can work so well in concert.

As far as why tests need to be in public, the primary reason is because lots of folks need their tests to be compiled. My team at my 9/5 codes their tests in CoffeeScript which needs to be compiled. And because the tests are themselves wrapped in AMD, we benefit from all the requirejs path checking, etc. I can see how that would be a bit of a pain if you are coding in straight JavaScript, but I think its a small price to pay for getting to take advantage of all the other things Mimosa will do with your code as it makes its way from one place to the other. In some cases having mimosa running is essential. One of the things that happens as a _spec file travels is mimosa-testem-require notices the file is a spec file and updates the testem configuration.

Let me know if you have any other problems!

@zaceno
zaceno commented Sep 1, 2013

Thanks for the great explanation. Makes perfect sense to compile before tests. And pretty damn cool indeed :)

I have another "issue" that took me a while to figure out, but I'll open a new ticket for that since it may warrant a whole other discussion. Thanks again – not least for the quick response.

@dbashford
Owner

Are your other issues the Bower ones?

Going to go ahead and close this out, feel free to open it if anything related pops up and is unclear.

@dbashford dbashford closed this Sep 1, 2013
@zaceno
zaceno commented Sep 1, 2013

Yup - the bower ones were the two other main stumbling blocks I've had so far. But things are straightening out nicely now. Before long I think I'll find myself writing mimosa modules of my own :)

Sorry to spam you with all these issues that would probably have been more appropriate on a discussion-board or something. To bad git hub doesn't have a "support-forum" type function. Thanks for being so helpful!

@dbashford
Owner

No big deal. I have a Google Group but is low in activity. I'm fine with discussion issues.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.