Skip to content
This repository has been archived by the owner on Nov 24, 2018. It is now read-only.

Write tests #9

Open
schickling opened this issue Jun 27, 2017 · 5 comments
Open

Write tests #9

schickling opened this issue Jun 27, 2017 · 5 comments
Projects

Comments

@schickling
Copy link
Owner

No description provided.

@schickling schickling modified the milestone: 1.0 Jun 27, 2017
@schickling schickling removed this from the 1.0 milestone Jul 24, 2017
@stevenvachon
Copy link

I wouldn't have released a v1.0 without tests.

@schickling
Copy link
Owner Author

I agree that having tests would have been great, but when deciding between keeping this closed source and open-sourcing without tests, we decided for the latter one. You're more than welcome to contribute some tests @stevenvachon 🙂

@joelgriffith
Copy link
Contributor

I've gone back and forth a lot on this, and eventually landed on functional tests vs unit. Once you start mocking the CDP module it gets pretty hairy and unmaintainable quickly (since it's an extremely wide API). Would be curios to hear others' opinions.

@adieuadieu adieuadieu added this to 1.1 in Roadmap Jul 29, 2017
@seangransee
Copy link
Contributor

+1 for the bulk of the tests being functional. Due to the nature of this library, unit tests wouldn't give me a ton of confidence that everything works properly.

@adieuadieu adieuadieu moved this from 1.1 to 1.2 in Roadmap Aug 2, 2017
@geoffdutton
Copy link

I just noticed this thread. I ended up covering with mostly unti tests to start without mostly to learn the code base. See #188. I'll admit it's kind of messy, but hopefully it's a good start. I was kind of bouncing all over the place as I learned how each class is used (and using TypeScript for the first time).

I think the unti tests come in handy for a sanity check. As I was writing the tests I found a few spots where a method wasn't being called, i.e. const val = client.someMethod vs const val = client.someMethod(), and some if/else logic issues. Also, a few spots where the host/port wasn't being passed. It seems like the underlying chrome debugger protocol could change quite a bit, so I think unit tests can help ensure we're calling/using CDP correctly as it changes. The other thing is testing logic of things like uploading screenshots to S3, or a feature like clearing the input which involves a series of CDP calls.

Having said that, I think functional tests will be very necessary. In the real world, it doesn't always be have as expected in unit tests, or the call to CDP isn't quite right, etc. I think writing out some known HTML with form inputs, missing selectors, etc. would be helpful to test against, and serve that up locally and/or reference them on Github. Thoughts on this?

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
Development

No branches or pull requests

5 participants