Next newsletter goes out tomorrow - join here: mobirony.ck.page/4a331b9076

I’d be curious to see more testing content, I switched from React to Angular due to work and this was the first time I’d seen jest tests written in a familiar way.

@acerunb8159

11 ай бұрын

welcome to the dark side

@nick.h7566

11 ай бұрын

You may rest now brother, you are safe here.

@rubenheymans1988

11 ай бұрын

and do you prefer angular or react?

@MrKlaygomes

10 ай бұрын

Same here. I would love to see more.

@moveonvillain1080

3 ай бұрын

​@@rubenheymans1988 React. All day everyday React. I also have similar story to OP but I still prefer React even though my job needs Angular.

For the tests shown in this video I would use Cypress component tests not Jest. This video is more about UI and less about logic testing. Jest cares about line coverage not UI elements. If you run Jest with code-coverage flag it is not going to care about what the UI has only the logic. I don't even use TestBed on most components I simply mock out whatever the component constructor needs and call new Component(mock); since it is just a class. I make sure the constructor is doing what it should for the first test. Then I make individual tests for each function on that component while mocking out any functions I am not directly testing. This gets you logic code-coverage with Jest . To make sure the UI is behaving I use Cypress component tests. Cypress component tests would make sure certain classes are on elements and the structure of the html is what it should be for every situation.

@MrKyuubiJesus

11 ай бұрын

I feel like your approach is very good. Test complex logic with Jest and check if people can do tasks/routines with e2e tests. App will be pretty stable without excessive work on adapting rewriting and debugging tests to fit changes in code.

@HaZzZemc

11 ай бұрын

Interesting approach, do you also get code coverage from cypress tests? If so, can you explain how? I tried to implement parallelization and code coverage reports with cypress and was totally a hell

@FCHFlo123

11 ай бұрын

you're right. But there are sometims some points where you already installed jest and don't want to install another dependency.

@pashabiceps95

2 ай бұрын

yes, it seems everyone is confusing e2e tests with unit ones. It is so ennoying.

Can u do more videos on testing please? I normally spend 60% of the time on tests

@JoshuaMorony

11 ай бұрын

Yes - I've got at least 2 more coming up soon. I'm actually surprised to see this video do reasonably well, in the past people didn't seem as interested in my videos on testing, but I love the topic so definitely expect more.

Very nice intro, and indeed it would be nice to see more content on this important topic! I love the way you explain how testing can seem intimidating from a distance, and that one must be confident that things stop being scary at some point. Testing is not an easy task, and often developers get lost chasing coverage for the sake of it (and the approval of the management layer that goes with it). They do it without really wondering whether their tests make the app safer or not, they just see it as a tedious task "that must be done juste because".

Your videos are pure gold! I never miss any of them. Sometimes, I feel like your videos are a bit too fast. For non-English speakers like me, it's quite challenging to keep up with this pace.

I eagerly wait for your new video. Thanks for sharing your expertise.

Really good mate , keep going

Thanks for the video, I hope you can have more videos in TDD approach.

Hey Joshua, Really enjoy and appreciate your videos. Currently I'm developing a simple app to learn how to use Signals as much as I can and I got myself with problems on the initialization of some read-only signals in the service. That says, I think it would be nice a video about doing authentication with signals and how they interact with the new functional Guards.

Love this!

Hey Joshua, great video as always, I would love to see more videos about testing angular apps, maybe in the same spirit of the reactive coding series (focusing on the reasoning behing the implementation). One small feedback about this video is that the test implementation is "pasted" on the image right away instead of being typed or highlighted in some way, which is a bit dissorienting (at least to me), it would be great if you highlight the newly added text in some way when "pasted".

Nx workspace provide jest as their default testing framework. It's good to see Jest content. I've written unit test cases for two applications and it was fun.

For unit testing of Angular components, I followed Shai Reznik method and now I use the TestBed to create the tested component in isolation, by injecting its class in the providers array. This way we don't need to call the constructor manually. I don't use the compileComponents() method or the detectChanges(), because I never ever test the DOM in my unit tests. Also, this allows you to get rid of the possibly nested dependencies with multiple services.

1:58 this called the “One Logical Assertion Principle” in TDD. It is not strictly enforced but it is highly recommended whenever you can. Logical assertion can be multiple assertions but together will be one logical assertion.

great video! now if possible please do share how you recommend approaching testing for smart components.

@JoshuaMorony

11 ай бұрын

That video will be coming out next week :)

more testing pls

Thanks for the video, well explained, i'd be really interested to see some NgRx test content :)

@JoshuaMorony

11 ай бұрын

Next weeks video isn't specifically about NgRx, but it will touch on the RxJS/Signals approach I've been talking about, which is very similar in concept (e.g. essentially "actions" that are interpreted by "reducers" to produce state that is retrieved through "selectors")

@davidcoolledge3588

11 ай бұрын

Great. Looking forward to it

Interested in more testing content

I would say that tese are more likely Integration tests and not unit testing. If you do only unit testing you don’t need the TestBed module and just create a new instance of the component before each test with all its providers mocked. We have recently done this on our project at work and reduced the test execution dramatically, for instance a test re-written in this way was reduced from 66 ms to 3 ms, which makes a huge difference on a big project.

@JoshuaMorony

11 ай бұрын

I know people are going to have different opinions on what constitutes a unit test - depends on what you want to define as a "unit" - and since my tests here involve the DOM I'm sure that will violate some peoples definition. I find it useful to think of these as unit tests though, where I am testing isolated/individual parts of components/services with any dependencies mocked, then I consider integration tests as anything testing where multiple components/services are working together, and then E2E tests as testing the application as a whole. As far as I'm aware, TestBed isn't really specifically slower, but since you are configuring a test module if you are including things that don't necessarily need to be then it could lead to slower tests. I haven't really done any experimentation myself though, and at least for now if you want to use the inject function for DI TestBed is now necessary.

@MR-su4di

11 ай бұрын

@@JoshuaMorony I'd love to see of you way of testing. Now especially integration and e2e, this is one of the first examples that speaks to me and allows to understand an approach to testing :D

it will be cool if you make a video about testing smart components

@JoshuaMorony

11 ай бұрын

It's already filmed and likely coming out next week :)

Hello, it's nice show of TDD, but I do not get the point of testing a component like that, tests like this seem to provide very little value and are time-consuming (both maintenance and creation) I feel that testing such a functionality is great job for e2e that you have mention there already is there (maybe next video on those ? :D ) and saving unit test for testing deep parts of business logic, algorithms etc.

@JoshuaMorony

11 ай бұрын

You can decide whether it provides any value in specific circumstances, but generally it just gives you a greater level of granularity and faster feedback. Given the "delete" functionality for example - I could (and did) write an E2E test that tests clicking the delete button and removing a checklist. However, if that fails I don't specifically know where/why it failed - with these more granular tests I can more easily see that it failed because the "delete" even did not emit, or because the "remove$" source in the service was never next-ed, or because the logic in the service for handling the delete is not executing properly, and so on. Unit tests are generally quicker/easier to run so we get this feedback faster, and we can also see specifically where a problem is. So generally, I like to use E2E tests for broad user story style tests, but mostly I focus on having more unit/integration tests (maybe something like 5-10 unit/integration tests for every E2E test). This is also just my preference though, testing it a highly opinionated thing

we want a repo to take the project, thank you!.

Would you please give an example about testing switchMap observables using observableSpy

@JoshuaMorony

11 ай бұрын

Let's say you had a "pageData" observable that uses a stream of the current page that switchMaps to an API call to fetch the current page data. Likely in this scenario I would do something like "next" the currentPage, and check (using mock HTTP) both that a request to the appropriate URL was made (e.g. /api/currentPageValue), and that the result of that (mocked) HTTP request is assigned to whatever it is supposed to be assigned to (in my case that would be the state signal). I generally take a behaviour based approach like this - if you want to get more granular with unit testing streams you might have to look into doing marble tests.

Hey @JoshuaMorony, thanks for your video. Is data-testid-* attributes are removed on build step ?

@balazs8351

11 ай бұрын

Afaik data-* attributes are handled differently by Angular. Try to use [attr.data-testid].

@JoshuaMorony

11 ай бұрын

No - these same test ids are used for my E2E tests as well

please make an integration test video

This video is for me. :)

I would've take another approach with the tests. First of all, data-testid are good, as they do not break the tests due to change implementation in the html. But it also contaminates the markup and adds noise with the sole purpose of testing. I would try to avoid it. And I'd also install testing-library. I feel it's an essential as it makes tests more user-driven and way less verbose and imperative, and much more declarative. Instead of checking an element "exists". You just need to ask "is the content of the empty tag in the screen?" and assert the value.

Writing tests would be good if it could bring extra-value to customers. I've tried suggesting writing tests at our company, but the problem is that we cannot bill our customers for the hours we would spend writing them.

@adambickford8720

11 ай бұрын

If you bill them to fix bugs, you're unscrupulous.

@kjn5991

11 ай бұрын

@@adambickford8720 We don't bill bugfixes. Only the time spent on adding new features or modifying / removing existing features.

@balazs8351

11 ай бұрын

That's a huge red flag. Try to find an other company.

@kjn5991

11 ай бұрын

@@balazs8351 Well, it's a rather young and small company (12 people) and there is constant discussion for making things better. But in order to include testing in our budgets, we need to explain a good reason for our customers to pay that extra-time which does not provide for the actual business logic or UI-elements.

@JoshuaMorony

11 ай бұрын

This can be a hard problem to approach for sure - consider this from a different perspective though. Say you're a dev agency that uses TDD when building projects, and it leads to the project initially taking 2-3x as long to build, meaning you are charging far more than some other agency who will do it for less - it would then be on you to demonstrate why going with your company is the better/safer choice even though you cost more. Just like people are willing to pay more money for a construction company who spends time on planning/blueprints/compliance/quality control when building a house, even though it's faster/quicker/cheaper to just start slapping some beams together (until the house falls down or catches fire due to dodgy electrical wiring of course). This is a much harder sell from the perspective where this was not part of your strategy initially, it's harder to go back to a customer and ask for money for a thing you are saying is important but didn't do initially. Also, to be clear, I'm not saying devs who don't use TDD/tests are dodgy - it's possible to achieve good code/practices without tests - the analogy shouldn't be taken too literally.

Many thanks! A good one. Just a small note: It's too fast.. would be much better if you could be a bit slower! Thanks again.

What it really doesn't click with me is that kind of a very strange syntax with the tests.

Have you considered creating a discord server for you and your viewers? :)

Since this is mostly about Unit Testing in UI, something that never should be unit tested. Call to an API, basically assume it is always down when your CI/CD pipeline runs. Yes, if it is a solo project you could bring it back up but that will not be the normal case in bigger projects. Instead test the setup of payload to the API and different returns from the API. This means that all API calls should be sort of handled in three functions.

@JoshuaMorony

11 ай бұрын

I get that you have a different philosophy to testing, but there isn't a problem with CI and APIs here, any dependencies are mocked - in any case, the "dumb" components don't generally inject dependencies and they almost certainly won't be making API calls.

@deatho0ne587

11 ай бұрын

Yes, talking about later "dumb" components normally are fine, since they are by definition "dumb". I keep UNIT testing away from APIs, but integration or e2e goes through them.

how to test complex and smart components? how to mock services and best autoinject them? the simple stuff is too simple...

@JoshuaMorony

11 ай бұрын

I've already filmed the next video on smart components/services and it will probably be out next week

Even for the most simple example you are already using a random custom library... That way is kinda hard to prove your point.

@JoshuaMorony

11 ай бұрын

It's not required, just makes testing observables nicer - it's actually the only third party lib I ever use for testing

@BGivo

11 ай бұрын

@@JoshuaMorony I had a comment about this as well. What's your reasoning for not using the default jasmine/karma? If you did, wouldn't they have their own Spy you can utilize to simplify things instead of this other external library?

@adambickford8720

11 ай бұрын

If you aren't using 'random custom' libraries, you're working on a toy project. You can't fail.

@balazs8351

11 ай бұрын

@@BGivoKarma has been deprecated recently by Angular. Also jest runs tests much faster by default.

@BGivo

11 ай бұрын

@@balazs8351Thank you I didn't know it was actually deprecated.

I hate how unit testing is becoming a standard. All of my 10 years of experience in coding, and I can't find a job because no one cares if you don't write unit tests. I'm trying to learn it but I just can't understand their importance. I write my code cleanly with error handling and comments. God I'm starting to hate this profession, maybe it's time for me to quit and pursuit my dream as a singer.

@JoshuaMorony

8 ай бұрын

To me the key importance is that it automatically documents and validates that the code does what it is supposed to do. Initially that might seem a bit pointless, but if you come back to the code some months later, or maybe another dev on your team does to add some new features, fix some bug, whatever - they might make a change that introduces some regression, but because the code is well tested they can't get their code past CI because the tests are failing. They can immediately see the problem and fix it, rather than sending their code to be reviewed which creates a longer feedback loop, and likely that code will make it past the reviewer as well because how are they to know this broke the purpose of some code that was added 6 months ago. So I think tests allow you to, in the long run, work much more quickly and confidently.

Testing simple things is pointless. Testing complex things is hard/impossible. I guess the only situation in which it could work is when many simple things come together to become something complex. That way you can test those simple things separately

@balazs8351

11 ай бұрын

Testing coverage also depends on business domain. E.g. in healthcare if you want your product to be categorized to a certain level, then you have to have 100% code coverage to audit your application based on regulations.

@JoshuaMorony

11 ай бұрын

My view is that tests should test that the application does what it is supposed to do, and if there is ever a situation where the application does not do what it is supposed to do (even something as simple as someone changing/refactoring code and messing up a (click) handler) then there should be a broken test to account for that - ideally pointing to exactly what the problem is (e.g. x should have emitted y but did not) - so in that sense I don't see testing simple things as pointless. Do you have an example of what you mean by a complex thing that is hard/impossible to test?

@krzysztofprzybylski2750

11 ай бұрын

@@JoshuaMorony if you require a code example I sadly can't share since it's proprietary. But I made a customizable numeric input for angular. You can select your decimal and thousands separator, your digit grouping (think Indian lakh), and handle percents that can be inputed as in percent form, but need to be stored as decimals underneath. Oh and both dot and comma should just be replaced with whatever the separator is chosen by the consumer of the component. I ended up with API that allows you, among other things, to have custom functions for transforming between displayed value and value stored in form. It also has some default modes it can work in for most common use cases. PS. I would love to test it since that complexity is a nightmare sometimes

what's new? it is pretty simple standard thing