Comments (7)
I think @anishkny is looking for a more rigid way of testing the API endpoints, which I think is fair. Our postman collection could certainly use more work/polish and beyond that it doesn't provide a more real TDD approach that's designed to actually try and break your backend.
Another key insight brought up here is that we could create "export to [your ideal testing tool]" by doing some simple wrappers around the Postman collection. No idea how difficult that would be to do, but I'm all for enabling RW devs to use their favorite tools while building the apps 👍
from realworld.
So I like this idea as well and I started playing around with Newman to see how useful this could be and how far off from being useful now it was and I actually made some pretty good progress (because it wasn't really much work).
So I pushed a branch called add-postman-newman-cli-runner, I haven't issued a pr yet, I kind of wanted everyones thoughts first.
So if you pull down that branch and
- Install newman
npm install -g newman
- cd into the api folder and run the follwing command
newman run Conduit.postman_collection.json -e Conduit.postman_integration_test_environment.json
you'll see the collection tests being tested. :-)
I added an integration test specific environment file, updated a few tests that are failing now to only run in the normal environment, and moved the Auth tests to the top of the collection so they are run first.
The win here is that this would allow us to create a Travis CI build and have a requirement that the build passed on any collection updates before they are merged to master.
Let me know what you think and I can create a PR.
from realworld.
Can you clarify what problem we're trying to solve here? What purpose does automated tests provide that the Postman tests do not?
from realworld.
Wow, this is awesome! I think we should def implement this 👍 Thoughts @gothinkster/realworld-admins?
from realworld.
This is a great idea. I had a similar plan to help automate testing for all backends. Although I think we need to baseline the current spec and test before we can start implementing this with all the backends. The current spec needs proper response codes and standardised error messages along with validation criteria. Currently these things are being mixed up with different backends since there's no guidelines set in the spec.
from realworld.
I was thinking of this more as a way to automate the test of the realworld spec itself as it evolves, not necessarily for a developer to use during development. They have the postman collection and now there is a swagger spec they can use. The thought here (at least to me anyway) is that as we update the spec/postman collection, for example updating a response code, as that pull request is issued to master, the automated test could run and we would know right away that either a test needs to be written, or the change broke the current spec/collection.
It's not 100% now but I think even in it's current state it would help us validate any changes to the collection without having to force all the current projects to implement every change immediately. If they wanted to have a Travis CI build automated and/or always keep in sync with the realworld master they could, but the realworld master automated build doesn't necessarily have to affect every downstream project immediately.
At least that's the way I drew it up in my head :-)
from realworld.
Agree with both @Cameron-C-Chapman and @SandeeshS — we def need a new detailed spec, and the Newman tests can/should be upgraded to match once it's ready 👍
I just messaged @SandeeshS on gitter to see if I can help at all with getting the new spec done & I just merged @Cameron-C-Chapman's PR into the repo 💯 Awesome work!
from realworld.
Related Issues (20)
- [Bug]: Line breaks not showing correctly HOT 1
- [Bug]: Immediately signed out after logging in HOT 3
- [Backend] Remove Response Envelopes HOT 5
- [Bug]: When try to build HOT 5
- User registration success status code is 200, but docs/swagger show 201 HOT 1
- [Bug]: server ERROR 500 HOT 2
- [Bug]: CORS Error HOT 9
- [Feature Request]: offline functionality HOT 2
- [Bug]: Demo server status is 503 HOT 1
- [Feature Request]: Vuetify in Realworld example HOT 1
- [Bug]: Continuous modification of user information results in an error HOT 4
- Try this HOT 1
- [Bug]: demo APIs down? HOT 2
- [Bug] initialData.data from route loader is always undefined HOT 1
- API server doesn't work HOT 1
- [Bug]: Heroku Deployment failed
- [Bug]: API doesn't work HOT 4
- [Bug]:CORS Issue HOT 1
- [Bug]: Demo backend is down HOT 2
- [Bug]: Site Not found HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from realworld.