For testing an application, I would definitely start with integration/UI testing, and when you've got good integration coverage you can start to beef up unit testing individual logic components. Adding automated testing later in a project's lifecycle is probably best starting out with integration testing as well.
For writing a library, I find it best to do strict TDD, unit-testing each method before integration testing the whole thing. This helps you make sure the small components each do exactly what you intend, without necessarily mandating how they should all be used and work together. It's much harder to know how a library will be used compared to a framework, so you really need good integrity at the micro-component level.
Another things I've come to like is to focus on inputs/outputs. Mock only when absolutely necessary, which is usually when testing a method with side-effects (which might actually be a code-smell). If each component is well-tested, then you can safely use that actual component in other tests, rather than needing to mock it.
This makes a lot of sense - thus far I haven't attempted a library, these have all been applications, which may explain this difficulty in knowing where to start. I like the rule of thumb of applying mocking judiciously - I do strive for small pure functions where possible and this is a good litmus test to see how you're doing.
Thanks!
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Like all things, it really depends.
For testing an application, I would definitely start with integration/UI testing, and when you've got good integration coverage you can start to beef up unit testing individual logic components. Adding automated testing later in a project's lifecycle is probably best starting out with integration testing as well.
For writing a library, I find it best to do strict TDD, unit-testing each method before integration testing the whole thing. This helps you make sure the small components each do exactly what you intend, without necessarily mandating how they should all be used and work together. It's much harder to know how a library will be used compared to a framework, so you really need good integrity at the micro-component level.
Another things I've come to like is to focus on inputs/outputs. Mock only when absolutely necessary, which is usually when testing a method with side-effects (which might actually be a code-smell). If each component is well-tested, then you can safely use that actual component in other tests, rather than needing to mock it.
This makes a lot of sense - thus far I haven't attempted a library, these have all been applications, which may explain this difficulty in knowing where to start. I like the rule of thumb of applying mocking judiciously - I do strive for small pure functions where possible and this is a good litmus test to see how you're doing.
Thanks!