Testing

[michael-small]

In my attempts with the form group setting issue https://github.com/timdeschryver/ng-signal-forms/issues/26, I have found myself wanting tests. So I made some on this branch of mine that was just focused on getting tests started: https://github.com/timdeschryver/ng-signal-forms/compare/main...michael-small:ng-signal-forms:add-testing-library-tests

My question(s) in regards to tests

• Are you interested in having tests for the project
• Is this type of test, using @testing-library/angular, appropriate for this project?
  • Why I ask: I know you literally work on the library. But for context: I write what I am comfortable with writing and understanding. I have used Angular Testing Library a little bit. I have done limited unit testing and I mostly do Cypress component testing. Even if the thing I am testing is not a component itself, but I just find it easier to grasp. I know this type of testing isn't always optimal or relevant, but I find this is more understandable than unit testing and I would rather have well intended tests I personally find meaningful rather than not writing any tests.
  • All that said, I think this probably isn't the most relevant form of testing that this library could stand to use? I imagine it would be more like unit testing, rather than component/DOM centric approach. But that is out of my wheelhouse, though I want to help write tests.

If you think it is reasonable to use @testing-library/angular for the project, I would like to add a lot more tests, at least ones to bolster the form group setting issue. And with the ones I made on that branch, I imagine they could be better (I see you have articles on using Angular Testing Library that I haven't read yet), but I don't want to polish them or write more if you think they aren't the most appropriate for this project.

If you think it is worth it to have tests but a different type of tests, I would like to learn how to make those. But if you are fine with me using Angular Testing Library in this weird way, then I will probably proceed with writing more.

[timdeschryver]

Hey, that's a great question. It has been briefly discussed with @goetzrobin before. Currently the library has no tests as it was just a POC. If there isn't a lot of adoption I personally don't want to spend too much time in it (I know, sorry 😅). At least some e2e tests (using Playwright) can be useful to test the example forms in the repository.

[michael-small]

Ah I see, it would make sense to not have tests if it is a proof of concept.

My point, directly about adding tests

At least some e2e tests (using Playwright) can be useful to test the example forms in the repository.

I have not used Playwright before, but it sounds nice. I will try to get some tests going for that when I take another go at the validator + value setting. Thanks for clarifying.

My opinion on adoption as a potential adopter, since you mention it

If there isn't a lot of adoption I personally don't want to spend too much time in it

Makes sense. Personally, I think a lack of tests may be keeping back some potential adopters. I was going to make the case to my work's team to pull this library into a project, but no tests among other other things made me cautious. It makes sense now that you clarify the intent and scale of adoption. Thank you for clarifying, and what is already here. It makes sense, you do a lot of great stuff and this is just one project.

[timdeschryver]

Yea, it's a "chicken and egg problem" when it comes to tests <> early adaptors 😅 To be fair, it started as a POC but it currently feels like we're a step further at the moment. So I'm not against it.

If someone wants to put time into it, I will definitely take the time to brainstorm/review changes. With any library that you want feel comfortable with, and want to use.