Good points, thanks for sharing!

On Wednesday, December 6, 2017 at 2:38:03 AM UTC-5, Zlatko Đurić wrote:
>
> Hi Brian,
>
> I definitelly think you could do that. Just as you run "karma start", you 
> could also run "mocha". The problem karma is solving is not simply how to 
> run tests though. It's also how to setup the whole environment. Sure, you 
> can mock an HTML element, run a spy on that element. Then you might need to 
> mock an input field. Then video tag. Then placeholder text. Then 
> localStorage. Then more and more. Finally you end up with phantom.js - the 
> whole browser emulated in JavaScript. Then you say, "what the hell, if I 
> mock the whole thing, I might just use the whole thing directly". And you 
> run karma.
>
> Small unit tests make sense. But plenty of tests you might write involve 
> "document.querySelector("button").click(); fixture.detectChanges()". So you 
> have to emulate at least 3 things there. So karma helps you not to.
>
> If you have 1000+ unit tests, that's awesome! But if you have problems 
> with these, you might be better off thinking about your test setup instead 
> of runner. Perhaps you can only run a subset that's being worked on. There 
> are many scenarios and it depends on what you're doing and what problem 
> you're solving.
>
> Zlatko
>
>
>
> On Tuesday, December 5, 2017 at 9:17:11 PM UTC+1, Brian wrote:
>>
>> Hi!
>>
>> Currently in the process of refactoring a good sized AngularJS+ES5 app, 
>> with 1000+ karma unit tests to typescript.
>> Started to think about all the issues I had wiring karma tests in the 
>> past. Things like test suites breaking because I added a new module 
>> dependency, then the service I'm testing is not even using that new 
>> dependency...
>>
>> Then I begin to wonder, why even use Karma for unit testing beyond, 
>> perhaps, a thin layer of DI testing.
>> In a unit test all dependencies should be mocked anyway, so why don't I 
>> save myself a lot of trouble, and just test directly the es6 exported 
>> classes using something like mocha+chai.
>> Abstracting the underlying technology should even help keep things clean?
>>
>> If I have concerns about the DI side I could always add a thin layer to 
>> make sure the angular service is really giving me the instance/type I am 
>> expecting.
>> Maybe I am too simple minded to see the issues with this... but before I 
>> go down this road of all but ditching karma completely though, I thought I 
>> might ping you experts to see what you thought.
>>
>> Appreciate any thoughts!
>>
>> /Brian
>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"Angular and AngularJS discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/angular.
For more options, visit https://groups.google.com/d/optout.

Reply via email to