Mojo::Pg example Blog

[Stefan Adams]

I use the Mojo::Pg example Blog as a boilerplate for almost every app that I write.  It's soo awesome!  There's only one thing that I feel is missing...  Unit tests.

I would like to do unit tests but I don't think I do them properly.  At one point I was talking about using testing by making blog posts and then checking that the blog post was created and visible on the website -- all by UserAgent calls.  @jberger very kindly informed me that this wasn't such a good way to unit test.  I was being too specific, I think.

So, what would a good and complete test suite look like for Mojo::Pg Blog?  I'd love to see this t/ getting added to the example Blog in the main Git repo.

I'd be happy to write the tests (I think I'm OK at writing tests), if someone could help with letting me know what should be tested.

Thanks!

[Sebastian Riedel]

> I'd be happy to write the tests (I think I'm OK at writing tests), if
> someone could help with letting me know what should be tested.

Well, just "OK" is not really enough. If i accept a pull request with
tests, they would have to be exemplary, because they'd be used
to teach how to write tests.

Maybe some day i'll get around to write them myself.

--
Sebastian Riedel
http://mojolicio.us
http://github.com/kraih
http://twitter.com/kraih

[Joel Berger]

On Friday, December 23, 2016 at 12:47:08 PM UTC-6, Stefan Adams wrote:

I use the Mojo::Pg example Blog as a boilerplate for almost every app that I write.  It's soo awesome!  There's only one thing that I feel is missing...  Unit tests.

I would like to do unit tests but I don't think I do them properly.  At one point I was talking about using testing by making blog posts and then checking that the blog post was created and visible on the website -- all by UserAgent calls.  @jberger very kindly informed me that this wasn't such a good way to unit test.  I was being too specific, I think.

Being specific is just fine. IIRC I was cautioning against your tests being too smart. Things like generating tests and test results rather than copying and pasting (usually with slight differences between tests). In your code DRY and clever are helpful, in tests it can mean that you aren't sure what the actual test is testing (since it relies on code which ITSELF might be broken to generate the test).

As to specificity, there are several levels which are normally used. Unit tests are a single class or method or function ... well, a single unit. These are tested in isolation to ensure they work. This might involve mocking out other pieces. This is call, unit testing. Then when you put those units together, sometimes with outside systems like databases, they are called integration tests. When testing a series of functionalities in a more real-world use case they are called functional or end-to-end tests. There can even be larger scope tests but they usually involve corporate process (UAT, acceptance, etc). Anyway, don't let specificity stop you.

[Stefan Adams]

On Sat, Dec 24, 2016 at 10:37 AM, Joel Berger <joel.a...@gmail.com> wrote:

Being specific is just fine. IIRC I was cautioning against your tests being too smart. Things like generating tests and test results rather than copying and pasting (usually with slight differences between tests). In your code DRY and clever are helpful, in tests it can mean that you aren't sure what the actual test is testing (since it relies on code which ITSELF might be broken to generate the test).

As to specificity, there are several levels which are normally used. Unit tests are a single class or method or function ... well, a single unit. These are tested in isolation to ensure they work. This might involve mocking out other pieces. This is call, unit testing. Then when you put those units together, sometimes with outside systems like databases, they are called integration tests. When testing a series of functionalities in a more real-world use case they are called functional or end-to-end tests. There can even be larger scope tests but they usually involve corporate process (UAT, acceptance, etc). Anyway, don't let specificity stop you.

Thank you!  This is again very helpful!  Having these definitions break down the types and purposes of tests, perhaps it will help me to focus better on writing better tests!

[sri]

Maybe some day i'll get around to write them myself.

The blog example now has tests too.

    https://github.com/kraih/mojo-pg/commit/6aec77beb9d92cd6e4780e10c7c5c222a7ff1a8f

--

sebastian

[Stefan Adams]

This is sooo great!! Thank you! I think that is such a tremendous addition to the already very valuable Blog example!! I think it will have a massively positive impact on people building testable apps. I'm so looking forward to following this example for testing my own apps.

--
You received this message because you are subscribed to the Google Groups "Mojolicious" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mojolicious+unsubscribe@googlegroups.com.
To post to this group, send email to mojol...@googlegroups.com.
Visit this group at https://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/d/optout.