creichert

> Terrible book.

Definitely overstated and not good advice for beginners.

My advice to beginners would be:

- Read all the Haskell books available at your disposal. (In addition to LYAH and the Hutton book, I would say Learning Haskell From First Principles and Get Programming with Haskell are great, https://www.manning.com/books/get-programming-with-haskell, http://haskellbook.com/)

- When you hit something that doesn't make sense in one source, try referencing it in another source.

- When you have some experience writing programs in Haskell, refer to some older books like Real World Haskell. There may be a few issues compiling the examples, but nearly all the techniques in the book are still widely used and you learn about the language has progressed in the last few years. This gives you a compass to read and maintain older Haskell source code).

- Read as much Haskell code as you can from popular libraries (Pandoc, XMonad, and smaller libs as well).

Looks like it was just updated at ~16:00 CST

Same here, mostly HTTP connection errors at various points in our infrastructure (us-west-2).

Awesome, glad to hear it. Definitely email me (Christopher - admin at assertible dot com) if you have any other questions or requests. I'd love to hear more of your feedback.

Blog post: https://assertible.com/blog/how-to-run-api-integration-tests...

The "Codeless" part is of course referring to the tests themselves, which are defined in Assertible.

Basically, ngrok is used to create a dynamic localhost tunnel to the web app which is built and run on CI. The dynamic ngrok URL is passed to an Assertible trigger which will run the API tests when executed.

Using this method allows you to reuse the same tests for monitoring and testing deployments.

Assertible (https://assertible.com) can do this. Designed to be a simple API testing solution with flexible automation and monitoring. Disclaimer - I am a founder.

GitHub apps are slightly different than OAuth Apps.

GitHub Apps are per-repository "integrations" that don't perform actions on behalf of a specific user and are installed directly to a repo (with fine-grained permissions).

OAuth Apps are the classic "integrations" installed by a specific user and perform actions on behalf of that user.

I imagine they have lower requirements because they are new, more specialized, and likely to be installed a little less.

Seems like it's allowed in the oauth form: https://pbs.twimg.com/media/C-7NlIzXUAErblp.jpg:large

Nice, thanks for the reply.

You mention CI so I'm curious. Do you have an automated continuous delivery process? Does testing fit into that (e.g. integration testing staging or dev services after deployments)?

I love how trivial it is to get unique disposable environments for each GitHub pull request automatically w/ Heroku.

This post talks about how to enhance review apps with automated post-deploy QA testing. In short:

- push commits to GitHub PR

- CI builds the code

- Heroku deploys code to a temporary environment

- Assertible runs automated tests against unique Review App environment URL

- Assertible flags GitHub status check as pass or fail, dependending on the results of the tests.

Interested to hear how other people are executing smoke tests & acceptance tests _after_ deployments.

I love how trivial it is to get unique disposable environments for each branch automatically w/ Heroku. This post enhances review apps with automated post-deploy QA testing. In short,

- push commits to GitHub PR

- CI builds the code

- Heroku deploys code to a temporary environment

- Assertible runs automated tests against unique Review App environment URL

- Assertible flags GitHub status check as pass or fail, dependending on the results of the tests.

Interested to hear your thoughts, or your testing process.

I wrote this post to explain how we automate post-deploy tests to validate all deployments of our API to staging and production branches.

The cool bit is that we use GitHub status checks to get tests results directly on our apps pull requests: https://s3-us-west-2.amazonaws.com/assertible/blog/assertibl...

I've been building a lot of API and web app testing automation and wrote an article to share what I've learned.

To sum up some bigger points:

- use as little end-to-end tests as possible

- when end-to-end tests uncover bugs, write new unit tests

- dilligently remove flaky tests and tests that don't provide value

- keep test data consistent, short-lived, and as small as possible

Would love to discuss problems anyone else has encountered testing APIs and web services.

(note: I am a co-founder @ Assertible)

Extremely good list and feedback. That will help a lot, thanks!

> Most people (at least myself) got into coding because they enjoy creating something from nothing. Maintaining and testing code is boring because it doesn't really do anything new, it's mostly fixing edge cases.

A good testing setup can be an alternative to redundant manual testing. This can really help speed up the creation process (for me, at least).

Drift is a great tool. Simple and effective way to get started w/ direct support.

Do you consider signing up to use an app with your email opt-in?

Have you ever tried to make a business out of selling an app online or in an app store? How did you get users?

I definitely don't agree with "tons" of e-mails but a few promotional emails is understandable. I also don't agree with the tactics used in the article, to be clear.

Link to the post: https://assertible.com/blog/test-every-single-api-deployment

We've been dog-fooding Assertible extensively since we released and it's now a primary part of our continuous integration/deployment setup.

I'm interested to hear what solutions others are using to test production / staging environments (automatically?).

I'd love to hear any feedback!

tl;dr

- Automatically test your web app when it's deployed to staging,production,etc.

- View the status of test runs directly from a PR using GitHub status checks

We're using this feature to test deployments on our staging and production sites. I'd love to hear any feedback from those deploying their web app's via GitHub!

I'm trying to make web service testing better with Assertible (https://assertible.com). Our motivations:

- For many small-medium sized organizations,developers manually test changes deployed to production and staging environments even if automated testing is already in place.

- Automated testing of a web service is much quicker and less error-prone then testing many workflows separately.

- Automating checks for security (coming soon), data validation (JSON, HTML), response times, and other assertions which are difficult for developers to test manually on every deployment.

- Scheduled health checks which let you know when the service is down (email, Slack, integrations)

Currently, we are focusing on automated post-deployment testing. Our primary goal is to connect into your current CI pipeline in a turn-key fashion; similar to how TravisCI and CircleCI work. We have support for GitHub deployments which can be used by services like Heroku, CircleCI, etc.

Here are some of the latest pictures of our GitHub status integrations coming soon: https://twitter.com/AssertibleApp/status/755115483209228288

I've used plain Stripe for SaaS product payments with two products (most recently https://assertible.com)

Stripe is very simple and has a very high quality API. They recently made some improvements to their dashboard for subscription management.

I've never used a service on top of Stripe for handling payments but I'd love to hear what others use.

Currently, assertible supports:

- HTML validation

- 404 link check

- page contains "text" (some arbitrary user-configured text)

- status code (200 by default)

- json validation

- max response time

You can find more information here: https://assertible.com/blog/simplified-assertions-for-testin...

We're looking into building out more assertions so definitely let us know if there is a particular type of test you'd like to run.

Hey Show HN! Co-founder here,

We are working on making Assertible _the_ turn-key web service testing platform which is very easy to use (similar to how it's only a click or two to setup Travis CI, Circle CI, etc).

Our current focus has been on integrating w/ the GitHub deployments API which this blog post discusses using alongside Heroku.

We'd love to get some feedback, especially from anyone using GitHub based deployments.

We've been working on a service to make post-deployment testing & monitoring web services turnkey (as simple as connecting CircleCI or Travis to a repository).

Assertible connects to a GitHub repositories deployment events and runs tests in response to successful deployments.

We are happy to listen & discuss any feedback!

She does mentions how to deal with that problem:

> If you do the first two things I told you, make something people want and focus, you’ll get growth as a result. And that means you can use growth as a test of whether you’re doing those two things.

Another book on the list I would consider essential is Parallel and Concurrent Programming in Haskell: http://chimera.labs.oreilly.com/books/1230000000929

I also thoroughly enjoy the Functional Pearls series, many of which can be found on the Haskell wiki:

https://wiki.haskell.org/Research_papers/Functional_pearls

Their naming is similar enough to leverage existing research literature, and knowledge, though. Those with a background in math can map some of their existing knowledge. Those without a math background have a more precise vocabulary to understand the concepts and research further. Even if they are a bit foreign, I prefer the attempt to be precise.

Using the trace trick needs to guard on False:

  myfun a b | trace ("myfun " ++ show a ++ " " ++ show b) False = undefined
  myfun a b = ...

See here for some other helpful trace functions:

https://hackage.haskell.org/package/base-4.8.1.0/docs/Debug-...

There is even a traceStack which will print a call stack if available.