Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bring more in line with the rest of the testing-library family? #4

Closed
kentcdodds opened this issue Apr 25, 2019 · 13 comments

Comments

Projects
None yet
2 participants
@kentcdodds
Copy link
Member

commented Apr 25, 2019

Hi there! 馃憢

I noticed that the API that this exposes makes it a bit different from the rest of the *-testing-library projects we have. Any interest in reworking it to be more familiar for folks used to the *-testing-library projects?

@timdeschryver

This comment has been minimized.

Copy link
Member

commented Apr 28, 2019

Hi Kent!
Thanks for bringing this up to my attention, I will have a look somewhere in the near future because I will also have to upgrade this for the Angular release.

Did you have something specific in mind? Because I could have done that on purpose.

@kentcdodds

This comment has been minimized.

Copy link
Member Author

commented Apr 29, 2019

Hi @timdeschryver!

A framework wrapper like this one should expose a function called render (or whatever makes sense in the angular world) which would render the given component to a DOM node and return the dom-testing-library queries that are bound to that node (using getQueriesForElement). It can also return a few other framework-specific utilities as well.

You can look at react-testing-library as an example.

From what I can tell, I think that this does that, but it's not clearly documented, so I just wanted to check.

The hope is that people who are familiar with the testing library family of tools will be able to write tests for components written in any framework without needing to change much vocabulary.

In addition, a requirement of the testing library family of tools is that the utilities exposed make it easy to avoid testing implementation details and hard (though not impossible) to do the opposite. I'm not familiar with TestBed.get, but if that enables doing anything with components that you don't typically do in source code then it's probably not a good utility to expose.

@timdeschryver

This comment has been minimized.

Copy link
Member

commented May 1, 2019

Thanks for the feedback @kentcdodds, I should've kept a closer look to the other libraries and I should have followed up on dom-testing-library.

I'm currently busy to align this library with the rest in #5

To provide some more info:

  • I have renamed the render function to render
  • Queries were already returned, but I've added the option to override the queries
  • The render result also encapsulated the fire events, this is to be able to fire an Angular change detection cycle
  • Removed the TestBed method (the testbed allows you to get everything that is injected in Angular's injection framework, e.g. services or components)
  • updated the dom-testing-library version to its latest version
  • Documentation needs to be worked on

I expect it to the merged somewhere later this week, at last during next week.

@kentcdodds

This comment has been minimized.

Copy link
Member Author

commented May 1, 2019

I love the changes 馃憤

It's up to you, but if you'd like, you're welcome to transfer this repository to the testing-library organization on GitHub. This will give your project more credibility as part of the testing-library family of projects with a unified mission of tools which help people avoid testing implementation details.

Again, totally up to you. I just want you to know we appreciate all you've done and you're welcome to join us if you like.

@timdeschryver

This comment has been minimized.

Copy link
Member

commented May 5, 2019

馃帀 This issue has been resolved in version 4.0.0 馃帀

The release is available on:

Your semantic-release bot 馃摝馃殌

@kentcdodds

This comment has been minimized.

Copy link
Member Author

commented May 5, 2019

Yes!! Sweet! It looks awesome! Any chance we could get an update on the docs site?

@timdeschryver

This comment has been minimized.

Copy link
Member

commented May 5, 2019

Yes, we will 馃槂
I'm going to upgrade some applications at work to use this version, once that is done I can start with the documentation 馃帀

I will also move this repo over to the testing-library family soon, is there anything special about this? Or can I just move it over?

@kentcdodds

This comment has been minimized.

Copy link
Member Author

commented May 5, 2019

You've been invited to the org 馃憤

@timdeschryver

This comment has been minimized.

Copy link
Member

commented May 5, 2019

Thanks Kent, I'll migrate the repo soon.

@timdeschryver

This comment has been minimized.

Copy link
Member

commented May 6, 2019

The library is migrated but it seems like I can't rename it to angular-testing-library

@kentcdodds

This comment has been minimized.

Copy link
Member Author

commented May 6, 2019

Weird. You should be able to. I'll look into it.

@kentcdodds

This comment has been minimized.

Copy link
Member Author

commented May 6, 2019

Ok. I fixed the permissions and also renamed it for you. Hopefully all CI just updates automagically :)

@timdeschryver

This comment has been minimized.

Copy link
Member

commented May 6, 2019

We'll figure it out soon enough, thanks again!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can鈥檛 perform that action at this time.