[EN] Angular Testing in 2024 - Interview

hello and good evening today I have my colleague R hanekamp and we will talk about testing in 2024 hi Rina hello Manfred hello and also hello to everyone who's listening hello again so we have a really exciting topic but we decided to postpone it to the end it's about all the things around end to end testing but we will start with a more general question question that comes quite often namely what should we test and how should we test it when does it pay off to test this or that exactly exactly so well we could say first of all if we look at the history uh the very early days where we started uh to work with ingula we used to kind of map the testing techniques which we've learned in the back end directly to angular in that meant that whenever we want to write a test we took a particular component or a service but we only took the class typescript class we tried to instantiate that class and we mocked everything away which was not part of the class so all the dependencies were mocked and this is then what we more or less tested and over the time we kind of realized that those kind of tests they don't give us that much benefit because I I mean I have to write quite a lot of code it's not easy and still I have to question myself what do I get in return do I catch now more bucks can I now really rely that my application is working I also have to maintain all these tests and this was was also very very often we asked ourselves is it really worth it and that's also why you ask the question what should we test which you or you're already implying do we actually have to test everything exactly because of that in well then we kind of started to realize that maybe it is better to kind of focus when we have a component to focus only on a particular on a component but not kind of instantiate the class but communicate with this component in our test why the Dom so instead of calling event listeners methods functions of that class we clicked on the button and then we hoped that of course then internally the event listen I triggered instead of kind of going to the component instance and asserting against the the value of a property we said no there should be a vis a visual output so somewhere in our Dom something should should should show should be rendered and we assert also against the Dom and then the last question was also was always okay but what do we do with the dependencies do we mock them if not what kind of dependencies do we want to keep and so on and so forth and there we usually say well if we want to test maybe a feature then it would make sense that we also add all the dependencies that such a feature has of course we would never send a request to the backend this is something we would all always mock but those Elements which are directly attached or which are part of of the T of the feature we want to test they are included in the test as well and that could be services that could be subcomponents pipes directives we would try to pack everything into that into that test them and I mean it's of course quite a lot but the advantage then is that first of all you have to do way more work for for a for a single test and for than what you have done before where you only tested the typescript class but nevertheless you had a much much higher coverage first of all and here I don't I don't want to say you do it for code coverage but it's really that you can say okay you see that the things that the elements that make up that feature they all work together very well this is what you actually want to test and you are very close to the reality so you you communicate with your component and with all its dependencies in the same way as your end users are doing it in the application so in terms of confidence it's it's it's it's way higher and this is something which we then realized might be the better way uh that we focus on those of of those kind of higher level tests of course this doesn't mean that we don't have to write any unit tests anymore so like we are only focusing on the typescript class that yes that they also are required but only for those parts where we say we have a lot of logic in in in in services or so their unit tests are perfectly fine but when I have actually no real logic and everything my application is doing is that it just loads data shows it and then sends it back to the to the server then doing unit tests where I test if a service is calling the htdp client and I have already mocked the hdp client this kind of tests doesn't they don't give you that kind of benefit back and might not be really good that's an interesting point because this means we move away from a paradigm that was quite common we move away from the testing pyramid to another shape of uh testing exactly exactly so we can call the shap the tasting the testing trophy which means in the middle it's quite wide and on the lower and on the on the top it becomes small again but the amount of unit tests that we write and also the the time we invest in in unit tests is not that large compared to the um how I call it component or integration tests that's true MH awesome awesome so this is a bit a change in Paradigm but as you see as you say uh the experience has shown that this brings more return on invest if you want to put it that way yes exactly and I also think then the question what do I have to test meaning what do I don't have to test is also not really important anymore because when I said before you have a service which is calling an H or which is using an HTTP client I'm not saying you don't test the service anymore but the service will be used in one of those integration tests together with your component and maybe also in cod in combination with some other tests with with some other services um that it is using so you will still test even those kind of smaller services but it makes more sense I think you have prepared one or two slides about this I have prepared them yes so um it's just let's visualize it because yeah yeah changes in Paradigm always a bit hard yeah so this is this kind of unit test that I was talking before that the term unit test has different definitions so when I'm talking to somebody about testing one of the first questions that I come up with is always what's your definition of a unit test and the way how we see it here is that a unit test tests only the typescript class even if it's a component it completely ignores the template which means the communication goes via the methods of the class and also via its properties and all the dependencies are mocked so we only focus on that small part there which as I said very often doesn't do that much this is the unit test and then the other extreme would be the component integration test again this it depends again on the definition but in general most important thing definitely is that your tests communicate with the component why the Dom that's crucial that's really important you don't want to mock the Dom don't do that and when it comes to the dependencies it depends so if it's a small feature I would try to put as much as I can into the into the into the test together if it's a huge application then of course just mocking the h B client will not be enough you will also have to kind of mock certain Services which are not which don't play a direct part in the feature for for example a user service so if I say I have an or two Library which I'm using and it's used because my component needs to know what the current user is then of course I will also mock that kind of user service or however you call it together with the HTTP client but um yeah I mean the user service it's important but it's not really the thing that I want to test when I talk about a certain feature M this is what I mean that you have to be a little bit uh selective when you have a larger application but in general the tendency is that you try to add as much as you can to your uh component and yeah test it like this so I think this transition over to the tting trophy away from the tting pyramid started already several years ago and at the beginning there was a lot of discussion meanwhile uh huge parts of the community seat that way at least in the front Community what does the angular team say about this yeah so for a very long time not that much we had of course the official documentation which kind of promoted very intensively the the test B approach but I think there were were even comments about instantiating a test like just calling new component something instantiating a component manually and three or four weeks ago there was a GitHub issue and I can also show that one I need to share my slides I need to share my screen there was a GitHub issue which started with a question testing question testing related question uh where somebody asked that in this case he wants to be able to write a test with an effect but he doesn't want to use the test bed in that in that case and then the discussion moved on and we had them at the very end so this is here Alex rabo from the angular CT him where they kind of where he kind of gave his generic view but what's really important is then here this last summary or his last statement where he was actually saying if you have test test then the first thing or where you actually start is always the test pad so you don't go any lower you don't instantiate the class on your own you use the test bed if you have a component you are of course you are also then using it you're also testing it while the Dom which means you have change detection in place you also have the the um the the dependency injection in place so all those things which are actually part of the angular framework are not also part of your tests they are also running uh because what they saw at Google because yeah they have to write quite a lot of tests uh that they saw whenever developers started to try to mock features or yeah parts of the angular API this always went completely wrong so there were there were a lot of struggles it could be that the test kind of produced completely wrong results which didn't reflect the real life behavior of of of of the component and it's not just and it's not worth it because very often we also hear this old argument well we can't use the test bet because the tests are too slow it's much faster if we instantiate the class on our own and here we also was saying that argument might be true but it's only true if you're using an angular version prior to version nine which is before Ivy was there because in the meantime the compilation is is already very fast and the performance argument isn't that the strong argument anymore I mean we can still say yeah there are some milliseconds which uh which you have to kind of accept when you use the test bed but you're getting so much back and I have seen so many issues coming just from wrongly mocking the behavior of of the angle API for example life cycle hooks when do I use when do I have to run engine in and when do I have to run engine on changes what comes first what comes afterwards I mean of course of course you can read it up but it's very easy that you that you get this wrong and then this is exactly what Alex was saying this is just small use case where you have a completely different behavior and your test doesn't is not worth anything it's even worse it gives you a wrong result and it completely you go drives you into a wrong direction so so don't do it use the test pad make use of the angular API of its life cycle hooks angular will do that for you and you just just focus on your on your test awesome it's really cool that we get those insights into the experien people made at Google and that we have an official statement regarding something like this from the Angola team yeah I also talked at the NG conon with Jeremy about this because what the angular team's always saying they are responsible when they introduce breaking changes they're responsible also to fix them and I said okay but what counts as a breaking change uh because if if there are no tests for a project how can I prove that this actually uh that the change in angular broke my application and he said you don't get that far in Google if you don't write any tests so everyone is is doing it and he says of course the test is the boundary so every application needs to provide the tests this is the specification and this is what the angular of framework is working towards yeah I think you won't even land your PR with any tests would very likely say no this will not be merged exactly exactly nice nice so let me also refer to other thing you said before you said when we move over to the testing graffy we also test on the level of the component which means we go via the Dome yes however Dome access was always a bit special in angular we had the impression that there is some room for improvement so how do you deal with this yes so in general I say it is crucial that you know how the test bed Works about the internals about the basic rules that you need to call the change detection the detect changes there also possibility to do this automatically you could also have to know how to deal with asynchronous tasks and um yeah how to dispatch Dom events because sometimes that's also necessary but in general if you really want to write large a huge amount of of of of component or integration tests you use also a library on top of it and there are three libraries which I can kind of recommend we can also include a fourth one which are the angular harnesses but that's more when you have the UI library but when you write really functional tests then I would then I'm sharing my slides again or my screen again then I would recommend um here we are NG MOX NG MOX is something is as the name says it's it's generally it's focusing on on the mocking part and yeah I've said before maybe don't don't over mock things but there are of course some use cases where you have to mock something and here mock is extremely powerful you can mock Services obviously you can also mock components pipes and directives that's where very easy so whenever you say Okay I want to test now a certain feature but this component branch of the component of the component subc components is something I don't want to have in my test because for whatever reason and I want to mock this Branch out then you can just say mock component you provide the subcomponent you want to have mocked and ngim MOX will take care of it and ngim MOX is something you can always use also in combination with other libraries definitely something you should have installed and then it's I would say you have to decide or you should decide between spec data spec data is a very generic testing Library it is of course as Ang Mox and Al and also as all the other ones they're all based on the test bed so they are not an alternative but they want to just make things easier for you uh spectator is doing quite a lot it has support for automatically mocking Services it has support for automatically calling the change detection or triggering the change detection and some other utility functions I would say definitely something worth looking into it but my favorite actually is the testing Library the testing Library first of all that's the real name so this is a library which is called testing Library it exists for different frontend Frameworks its initial or its first kind of version was for react but it has many bindings so also bindings to angular and for the angular part the main person which is responsible is team describer and he's part of the inur X team so he knows quite a lot about angula about the internals and I would say the testing library is in good hands of course also with the other contributors that that he has so there also some other very familiar faces there and why would why I actually want to recommend the the testing Library so first of all we see here the testing trophy from from Kent dots who was also the the initiator of the testing Library itself the testing Library kind of tries you to steer you into the right direction whereas spectator in a way says I'm very generic you can use me for different use cases I have the feeling that the testing library is highly opinionated that it says well we start at the Dom level we don't go any deeper so I don't even give you any functionality where you could actually access the component instance or something like this then you have to use the native tools and uh you also see here that all those functions that we have that get by roll uh what else is there I get by text for example they are all based on this kind of fact that you communicate with the Dom while your test M and and the testing Library also Mak make sure that asynchronous tasks are executed there are some internal functions there especially those functions which start with find so if you say your screen find by text or screen find by role then you have a promise first of all but inside of this asynchronous task they are making sure that the asynchronous tasks are executed and also the change detection is executed so you own for example you very rarely see a detect changes command or a te command when you use the testing library and in my experience those two things the change detection at the asynchronous tasks are one of the hardest parts so if the testing library takes them away that's already a very big win awesome awesome yeah good that we have such uh libraries that abstract all of this yes yes so what's with the rumor that Jasmine and orama will be de yeah um that's that's that's a rumor at least part of it so the angular team saids that they want to deprecate Karma in fact it's already marked or it's it's already officially deprecated and um first of all one has to realize that we are talking here about two different things if we say Jasmine and Karma because the main thing that the angular CLI provides Us in terms of testing the testing framework is Jasmine Now Jasmine is not deprecated it's maintained there is no reason why somebody wants to deprecate Jasmine but the problem with chasmine is it just provides you commands for writing tests and if we want to use um components which also want to render somewhere then the components inside of our tests will at certain point in time say document create element and then somebody needs to be there in order to fulfill or to provide his command and this calls for a web kind of environment and this is what karma is responsible for so karma is the thing that takes the chasmin tests and puts it into the browser and then the browser of course Pro provides it its native web API also provides the rendering and then the tests are running inside of the browser context and what's going to change is now karma so only this kind of mechanism to take the chest test and put it into the browser that's going to change we will now have the the the web test runner from Modern web um this is a modern version it's doing quite a lot of nice things already and um yeah ingula will just replace Karma with that one which of course also means we don't have to change anything so the code that you write is chasmine code that's yeah and since that's not going to change um it just maybe look we will I guess the UI will look a little bit better when we use the test Runner and yeah that's it awesome so what's with stuff like chest yes so the chest story is an interesting one because we have already chest support from the community for many years we have the enx integration of chest we also have the chip Builders so that's a that's a library where you can uh come up with your own bu builders for angular CI if you don't use an X and they as I said they are Community project so they are not officially supported and the team once after they have done the migration to the web test Runner so this is web test Runner has the higher priority but then they want to also integrate chest into the into the angular framework so that the angular C also supports it natively which means uh we don't need to use any Community plugins anymore uh we just say NG test and then there will be an official Builder provided by angular which will then run chest so chest is one thing that uh some people would like to use officially with angular another thing is weest yes yes yes so weest is I would say the newcom in in JavaScript we can say we have three major testing Frameworks uh Jasmine chest and mocha where chest is is is is top the top Runner and we test is something we see now more and more especially new Frameworks but also other Frameworks or meta Frameworks which also now pop up um uh provided out of the box or provided actually as the default um testing framework and vest has the nice advantage over chess that it's modern it's younger and it has some things which chess doesn't really have uh especially esm support So ecmascript module support uh we just just works with it out of the box in just we still have OS Script support in an experimental mode and I heard already some rumors that people say well they don't think that chest will ever provide stable support for OS script modules yeah we don't know we will see but but the reason or I think the important thing why esm or what is actually the reason why I mention it is that in angular all the modules are compiled down to esm and that's of course also very important that any tool which runs code needs to be able to understand OSP modules and this is what chest where chest is not good in but weest just provides it out of the box but when when weest was created is it was already clear that esm is coming and also typescript so also chest has been there for a very long time where typescript was not that popular and with weest it's a different story typescript is the is the language to go to and and and retest has also um you native support or first class citizen or SE typescript as first class citizen let's put it like this so we have way more um we don't have those kind of issues that those kind of Builders take away from us so we don't even see those problems they're doing a very good job but nevertheless somebody has to be there that who has to fix it and with weest it just runs out of the box now the problem is how do we get it into into angular yeah yeah yeah I would say that would have been your next question uh yeah um we test requires weat so that's also where the name comes from and the thing now is where we don't have real weat support we only have it for the def server but not full support and the only option that we have at the moment is that we use the analog framework because the analog framework this is a meta framework so that's the way how it is called it has different functionalities one of them is support for wheat and once you have support for wheat in angular you can also use vest so if you want to use vest then analog would be the answer yeah that's awesome it's an awesome Community project it was also featured last week at angon in Salt Lake City Brandon Roberts really does a great job with integrating this stack into angula yes yes yes and he also understands I think the needs the business needs because he says if you want to use weest then I'm not forcing you to kind of install or or or kind of consume the complete analog the complete meta framework you have only the the platform which is the basis the foundation the layer the main layer and then you can only use weest just very small parts of analog but you don't need to use everything if you don't want to have all of it that's an awesome Point yeah we can just add it selectively to the yes game exactly nice and I think you told me that uh the API we go with when using Vest really looks like the API we know from so not that break exactly exactly that's also a very important thing um weest says from itself that they are supporting chest Cod for 100% so there should be an easy transition path from um chest to weest if this would come up in the future again the the angular team doesn't really have support or doesn't really plan to use weest at the moment uh but from their side they also made the argument if weest gets a kind of a momentum and we see that the numbers are exploding we can already see momentum so I think I personally think we are already in it but it will take some years that that that weest kind of climbs up to the to the numbers that chest has at the moment but either way they saying well if we test is the number one and we need to support it then at least for the developers it's very easy to mark because of the compatibility cool cool so let's come back to the main topic about more Co grain tests tests on component level mocking a bit less um you told us before when we want to do component tests we can come from One Direction which is the direction of unit tests we at least use the same Technologies use for unit tests like chest or chasmine and add some libraries to the play like spectator and shimo or the tting library this is one approach but there is also another approach we can come from the other direction where we start with end to end testing Frameworks that also try to adopt themselves to this Middle Ground of going with a component testing so what can we expect in this area exactly exactly so this is something we have already for two years or so and I'm going to show the slides afterwards but just give you a quick of an overview what this is all about when you compare a toan testing code for example from Cyprus with Code test code written with chasmine or chest it doesn't matter you can see a huge difference in the readability uh because Cypress end to end testing is usually way shorter easier to understand way more you're way more productive because you don't really have to care with asynchrony or asynchronicity I won't ask a British person what's the real name of it and he said you can use both um change detection Dom events everything's there because the end to end testing tool is using a browser and the browser and everything it's just like a communication as you would do with an end user you don't need to control all these things and with the native tools or with the test but you have to do that now the idea was that they said what if we could use those kind of the the the the Simplicity of endtoend testing also for component or integration tests so because we know already that we want to test why the Dom so why not try to only take some parts of the application a component maybe some Services maybe some subcomponents also maybe give developers the possibility to decide what they want to mock put it into a browser run it as an application and then let the developers use a toan testing tools to test this particular component and this is this direction that you meant before where we are seeing endtoend testing Frameworks coming from going towards uh component and integration tests and um this slide should be seen here right here we have it so at the moment when we talk about stable Solutions then there is only Cyprus Cyprus has component testing support for angular and yeah you see it in the drawing so you can write integration component tests with Jasmine with and also with chest but you could also use Cyprus for it and if you look again at this kind of developer experience that you have with Cyprus component testing then you usually want to go with that part for integration and component tests as well there are some maybe some disadvantage you would have to you will have to pay a little bit in terms of performance uh Cypress component tests tend to run slower than the chess Min and chess tests but you gain so much in terms of developer experience that you just say it's worth it at least that's what the majority says and of course that also means that chest Chessman kind of the the use case for them falls down to unit tests where as we as we have discussed in the beginning we don't have so many of them anymore because yeah we don't have so much logic usually so that sounds awesome but I think that Cypress is currently challenged a bit isn't it yeah so uh the challenge for Cyprus at the moment is play rde we have have already play right for quite some years we actually saw it coming but we now in our we are now in a position where we would say yeah it's it's now becoming really serious and I have prepared here some slides as well let me quickly switch over right so what we see here are the download statistics for the last 5 years and the orange color shows Cypress so we see here this kind of success run we see that Cypress kind of climbed up very very quickly to to to number one and since 2022 we see that we have here I have here three different libraries of playright and the the way they all kind of make up playright but I can remove at least a playright and just leave it with play core and play test itself now the interesting part is depending on what you see as playright if you say playright core is the one that you count as playright then it would say the current number one and you see that the Gap is already increasing is playright if on the other side you say well playright test is more the testing framework because playright core can also be used for remotely controlling a browser it's not just only for testing but also for more but if you say no it's play right test only then there is still some gap between Cyprus and playright but looking at the numbers looking at the trend at the it's obvious that it is just a question of time until playr playright will overtake Cyprus and will be the number one so this is all different slope I guess yes and so they will meet soon exactly exactly and you and you also see here it's just between these two so if you for example say the angular has Partnerships the angular framework has Partnerships with other end to end tasting Frameworks like test cafe or night watch then you see that these two they don't play any role it's just about playright versus Cypress in that in that regard and there are some reasons why it is like this so I wouldn't say this comes as surprise because I mean we have we' we we've discussed this already in former interviews but we see that the advantage of PR are becoming more and more and more and from Cypress perspective there is at least that's the way how it looks like there is nothing how they which they can counter with and last year there was a Cypress conference there was also a video so it's it it's it's public information and in the video it was kind of mentioned that it is a possibility for Cyprus for example to use Puppeteer under the hood so that they are already using another kind of Library very very similar to to to to to to playright but not an inter testing framework uh because they see just it has yeah it can't follow up anymore with with playright so maybe they have to switch here a little bit but but then again um this kind of um the strategy that Cypress wants to evolve into Maybe um a better testing framework by using other Frameworks or by by providing testing for the complete stack so for units um component and end to end testing yeah we have it for component end to end testing but also for unit testing we don't have anything in angular this is something I already hear for a very long time and I don't see some some some new developments in that regard and the time speaks of that I I think uh to put it bluntly time running up for for for for Cypress so they have to do something and if it is just if and if it's just is that that they are kind of using a papeto playright under the hood maybe yes but um nevertheless in terms of in toan testing playright will probably win it or not just probably but I think I think we can uh already see this as a fact uhuh so why is play right that's popular what does play R in a better way yeah many things uh so first of all uh play rides com in from Microsoft which means they have an infinite amount of resources compared to to to Cyprus obviously um you know already how Microsoft Works that's actually it's an it's it's it's an Open Secret it has already been told also by microsof employees that whenever Microsoft wants to get into a certain Market that they will pick the number one leader they will try to kind of copy or try to do everything that they are doing but just doing it better kind of overtaking it with the resources that they have and then in a way becoming the number one and this is exactly what we see at the moment with playright here as well so we can say if you look at Cypress or the the reason why Cypress became number one is that you have a stability in your tests you can trust those tests and you also have a very good developer experience so it's very easy to write tests with Cypress and this is something which play understood they said okay we need to have both things stability and the developer experience but but but then something on top as on something on top as well and we know that Cypress has some yeah deficits when it comes for example to or which is due to this in browser testing so what cypess is do that the testing code always runs in the browser which means the majority of our testing code is as any normal JavaScript that runs in the browser it can't have full control over the browser which means we have some limitations we have some boundaries we have some constraints for example we can only control one particular browser tab I can't open three browser tabs in in Cypress and control off all of them at once that's not possible I cannot also just jump between Origins that easily because Chrome says you have JavaScript coming from that particular origin now you are somewhere else why should I allow you to execute JavaScript from that origin and and of course then this is something where particular application types can't be tested I mean luckily for Cypress we don't have so many use cases where we have multiple tabs but those things that do also exist which is a problem for them but what we have very often me the meantime is that I need to authenticate myself as a user so I'm going to a keycloak instance I'm going to somewhere else in order to to log in and then I have exactly this kind of problem now Cypress has done its best in a way to kind of mitigate it to make it possible there is for example s origin but I mean these are all problems we discussing here coming from the design of Cypress that the test runs inside of the browser and this is where playright immediately said no we are not going to do it like this we are running our test side out our test outside of the browser for example maybe a quick story that I might want to add it was asked once um by by some developers um for for the angular team why why they are not using for example Cypress if it's that it because it it's that good and the answer was well they say it's there is a click on a but but it's more like getting the Dom element and calling the click method on the Dom element that's really the same thing I mean in the end in most cases it doesn't matter if you call the method or if you really try to do it the real click but for the for the for the scope that that Google has or for the amount of users that Google has that really counts and that's one of the reasons why they why why they didn't use um Cypress now play says okay we are running the test outside we have full control over the browsers so all those kind of issues coming from running test inside of the browser just don't exist for us so they don't have to spend that time fixing all those things because it's just not a problem for them this is one thing the other thing of course is again this kind of backing up by Microsoft that they don't really have to earn money in that sense I mean of course at some point in time um uh somebody you also of course want to get money for for playright but that's another story but they have the possibilities to give away certain features for free for example par parallelization so where Cypress says when you want to run our tests in parallel then you need to use the Cypress Cloud that's a paid service yes but playright says well we don't need it you can do this on your own we provide parallelization out of the box MH so you get it for free you can run it shots and get it for free yes yes exactly exactly and then of course you also have the playright team which is also very good uh because the the the the the the original the core team is made up of former Google employees who worked on the Chrome death tools protocol so they know exactly how a browser works and then of course it's for them it's I would say easier to write a a framework a testing framework for a browser compared to somebody who might not have written a browser so far I see mhm that sounds awesome so what is the the interest of Microsoft into this or how do you think want they to earn money with it in the mid or long run they they also have something like the Cypress Cloud that's called Asia which is a completely different thing so if you compare it of course I guess yes yes which again I mean it also speaks for for for for for Microsoft or for play in that case because they say yeah we also have a cloud service which you can pay money for but you get way more maybe uh than I press can ever make up because again Asia is a completely different thing and they have an integration for play right into it as well oh yeah sounds good that means if we want to pay a bit we can run it in ASA if we don't want to pay to Microsoft we have to host it by ourselves exactly so if you want to support Microsoft then yes you can give them money oh yeah I think this is quite an honest business model because it gives people options if you want to have a bit more convenience then it costs a bit of money if you want to run it by yourself then yeah you can have it for yeah yeah so I think Microsoft is also very honest in that regard I mean they say as it is this there is for example this typescript Origins documentary where from typescript also comes of course from typescript and uh typescript comes from Microsoft and there they also explained exactly this kind of strategy we just pick the best product in the market copy it but just doing it better outperform them that's the way how it is nice nice but I think there is a little Dy catch when it comes to component testing oh yes no of course yeah you have a problem with playr when it comes to angular because yeah what do you do um if you have an angular application and you then say Okay obviously in terms of in to end testing playrite seems to seems to be the better choice so I'm going with play for into to in testing but what do you then do with component testing do you then use press yeah you can do it but then you still have the open question what do you use for those few unit tests you have you can then use chest or chasmin and then you have three different testing Frameworks just for testing and then there is also another framework which you actually have to use to write your applications with that's singular that that might be a little bit too much yeah and so you have at the moment I'd say it comes down to three different choices you can say as I said playright Cypress component testing or chest chestman you can also say no I bet everything on playwright I want to have it in the end to end testing I don't want to use Cypress because I just want to have a second um I just want to have two tools which would then mean chest or chasmine but together and here I would say with the testing Library so then you pick the testing library for component tests that's one way on how to go and then the last thing would be that you just um put everything on Cypress and use Cypress for in to testing for component testing and then of course yeah just ches me for for unit tests this is what we have at the moment at least that's that's the three choices yeah so I think you told me when you already have a huge code space if you don't start from the scratch then you would rather stick with your current Choice which might be Cypress if you start with a new project then perhaps it's rather play R in the short run with an another Library like the yes testing library or in the long run just a play right because in the long run it will uh support component testing is that right did I get yes yes so maybe I can even clarify it even more so I mean you know how it is uh we can always say it depends on what you should use yeah but but I think when it comes to n 10 testing I wouldn't say anymore it depends I would say in most cases playright is the better choice at the moment so a very clear statement in that regard I think the time has come that we say yes in most cases again I Leave myself a little bit of space but yeah I would I would use playright if I have a new project without doubt so I would immediately take it into a testing um if you have already existing tests as you said then there is a high chance that first of all the migration might not be that easy and second that maybe you have it under your control so there are usually developers who know how Cyprus Works they know about how to deal with certain aspects and then you might not have this kind of pressure that you say okay we immediately have to migrate Cyprus will not go away but you still I would say you should maybe start thinking or investing time a little bit maybe create a prototype or a testing balloon or however you want to call it where whenever you have new tests that maybe you want to try out play right for for in to testing so this is something which I would recommend and then again the decision is is yours you have to of course you have to balance you have to kind of compare the costs it would take to migrate from Cypress to playright and you also of course have to be know about the benefits as I said you get priorization you get also something which is called the trace Vier where you have for example in your CI a very good report telling you what went wrong with your tests you also get this with from Cyprus at the moment but it's coming with the commercial version but there are also some other some other features with from from playright that I've mentioned before yeah but then if you have an existing project it's really up to us I wouldn't say you have to wait if you say no we have already a lot of pain or huge problems with with Cypress then of course the answer is also very clear then please check out playright and in most cases you will be happy with it and then also that's the way to go the the the other thing um so if we say yeah um existing Cypress test versus non-existing Cypress test that's one dimension the other one which is special only for us angular developers is the question of component testing because there is alternative from playright at the moment but here also things are changing so there is one of our colleagues this is Junes unes Junes J from from France from where is he uh yeah Leon he's working on a on a playright integration on on an angular integration angular component testing integration into playright he is not alone there are also other yeah there's also other people who help him of course the playr team but also for example Brandon Roberts I've also seen me seen him in the GitHub discussions and somebody from from the Netherlands so they are working uh very very intensively on it and I think it will just take few weeks and then we have a playright component testing as well so in general if you have some doubts about component testing and you see you can wait for a few weeks then I would do it and then I would just really check out the first prototype that we have of the playr component testing for angular and then maybe the answer is clear awesome really great how all those drings come together and it's also great that we are in the fortunate position to give a recommendation because now we have the numbers as you have shown before I think last year this was not really the case there we already saw that play ride has quite a slope but the numbers were quite lower and so a definitive recommendation was not that easy then exactly exactly I think you always have to be a little bit careful if there is something new in the field they usually highlight only those things where they are better compared the old ones and maybe you miss that maybe some basic things aren't even available there and um of course also the kind of long-term perspective is also important but I think with playright with Microsoft in the back that the long-term story is not an issue and we also see that playright kind of has advantages in all Fields so yeah I would say it's now time to give a a clear recommendation for playright awesome so are all those topics covered in your uh Workshop you are doing a angular testing workshop with play R yes yes so in in in in in in in the play R version we have the first St with the playright basics and then the second day will be at the moment with with with with with with chest and there as I said we're using the testing library because I don't want to kind of I only have two days we only have two days so I can't use um playright and to end Cypress component and then also chest for unit test that's not possible and that's why we we go with chest but as soon as the playr brings out this component test we will use it also in the workshop and as I said it's just a question of of weeks or maybe even days yeah Easter is near so maybe we will get an EAS egg or what however you call it that would be great I think the next installment of the English version of this Workshop is in June so chances are high we also talk about the play RS component uh tests there yes yes so I'd say it's what the way how it looks at the moment it's quite quite safe to say that that that the June Workshop will already have the component tester mhm nice that's would be awesome so for the case you're wondering what we are talking about if you visit us at our website not o but angle then you see this guy here and then you can switch to English and if you scroll down then here we have have uh where is it oh Cypress Edition no we want to play Edition don't we we want to have Play Ride Edition so let me look it up yeah here we have it Play Ride Edition in June it's even us friendly it's on three half dayss and yeah here you'll find all the details the agenda and rina's picture and yeah all the details what you will learn in this course and of course then there is also a button to book your ticket it's fully online and yeah you can participate during three days are there practically exercises yeah a lot of them a lot of them so of course for the playright part but of course also for the unit testing part because as I've mentioned before it's crucial that when you have to use chest or chasmine that you know how to deal with asynchrony you also have to know what the test ped is all about how to use it because it will also play a role in play and also in Cypress component testing because under the hood they also use to test that but so yeah it's it's just important that you also know about the basic rules there as well makes sense cool yeah and I like the exercise part this is how we learn yeah especially people to deal with it yeah and also discussions afterwards so if there are some questions coming up or maybe a just pick out some exercises which I find interesting and maybe show a different variation of it or explain the the specific case awesome yeah Rina thanks for coming today thanks for sharing your extensive knowledge about all of this I mean it was not only knowledge it was also baked with Statistics and statements from the Angola team and things that happen in the community so it was really awesome big thanks for this yeah thanks as well see you arounds bye-bye goodbye yeah goodbye

Channel: Manfred Steyer

Views: 1,294

Keywords:

Id: MQd9yRBZSKY

Length: 56min 36sec (3396 seconds)

Published: Tue Apr 02 2024