On Sat, Dec 24, 2016 at 10:37 AM, Joel Berger <[email protected]> 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! -- 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/mojolicious. For more options, visit https://groups.google.com/d/optout.
