tag:blogger.com,1999:blog-6369418367411691447.post4951971888777884886..comments2023-09-23T03:42:22.937-04:00Comments on Mike Subelsky: The one best way I know of to write software testsUnknownnoreply@blogger.comBlogger7125tag:blogger.com,1999:blog-6369418367411691447.post-55599586774422297772012-02-03T11:10:28.127-05:002012-02-03T11:10:28.127-05:00I more-or-less use the same system.
Regarding arr...I more-or-less use the same system.<br /><br />Regarding arriving at "ill-defined domain models and internal APIs": I'm not a fan of test-driven design, and I find some anecdotal support for that notion here: http://ravimohan.blogspot.com/2007/04/learning-from-sudoku-solvers.html<br /><br />In other words, I think you should think carefully about (and occasionally refactor) your data model, and not be forced to do so by the tests.Jo Lisshttps://www.blogger.com/profile/14144537818667786891noreply@blogger.comtag:blogger.com,1999:blog-6369418367411691447.post-55728477486795020352012-02-03T11:09:16.095-05:002012-02-03T11:09:16.095-05:00This comment has been removed by the author.Jo Lisshttps://www.blogger.com/profile/14144537818667786891noreply@blogger.comtag:blogger.com,1999:blog-6369418367411691447.post-46768727908061689762012-02-03T10:42:16.713-05:002012-02-03T10:42:16.713-05:00I do the same thing. The only difference is I do c...I do the same thing. The only difference is I do controller tests for API related functionality and negative responses.<br /><br />Knowing what type of tests to use for any given functionality is what makes the difference between a good developer and a bad one.<br /><br />Bad tests actually slow down work and cause massive refactors to have to be made in my experience. Although, I might just be sensitive to that last statement because I'm in the middle of developing production code while refactoring bad tests and code from another developer.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-6369418367411691447.post-24274754034248523882012-02-03T10:16:34.614-05:002012-02-03T10:16:34.614-05:00I had a similar talk with Nick that had similar re...I had a similar talk with Nick that had similar results on my testing style, but I'm also a dirty mockist, so I still have a lot of unit tests, but they test as much in isolation as possible. The integration tests cover the actual traversal through the real codebase, and sometimes I (gasp!) write integration tests for API-level things in apps, working with real objects where it seems to make sense (for things that, if they were to ever be re-used, would be a separate Gem).<br /><br />I'm still experimenting with this, but it seems to be working for me so far, with nowhere near as much integration pain as I was having with <b>just</b> unit tests or <b>just</b> integration tests. And it's still pretty fast-running, since the only DB work is done in the integration tests. We'll see what song I'm singing in the next six months when I have to go back and work on something I write now. :)johnbintzhttps://www.blogger.com/profile/01869011517694873138noreply@blogger.comtag:blogger.com,1999:blog-6369418367411691447.post-76951375244111318522012-02-03T09:31:44.939-05:002012-02-03T09:31:44.939-05:00That's funny that you end up with lots of unit...That's funny that you end up with lots of unit tests. So far for me it's still the opposite but you may be working on larger/more complex projects. Glad you find this approach useful also!Mike Subelskyhttps://www.blogger.com/profile/03590094055236393140noreply@blogger.comtag:blogger.com,1999:blog-6369418367411691447.post-8863546050412037702012-02-02T23:33:03.455-05:002012-02-02T23:33:03.455-05:00I couldn't resist coming back and sharing a li...I couldn't resist coming back and sharing a link to an example.<br /><br />https://gist.github.com/1727873<br /><br />I substituted user, foo and bar to hide the actual domain but I'd estimate nearly 90% of my cucumber features follow the form shown in this gist.Anonymoushttps://www.blogger.com/profile/15964361079720234778noreply@blogger.comtag:blogger.com,1999:blog-6369418367411691447.post-23739068127627145492012-02-02T23:10:18.454-05:002012-02-02T23:10:18.454-05:00I do exactly the same thing.
The way I look at i...I do exactly the same thing. <br /><br />The way I look at it is that I'm using the integration tests to follow both the positive and negative paths that a user could take. Then I'm using the unit tests for the models and controllers to enumerate each of the possible wrong actions.<br /><br />I follow this approach to the point that if I see more than 2 paths in my integration tests I consider it a code smell.<br /><br />To me this seems to result in a few integration tests with lots of unit tests.Anonymoushttps://www.blogger.com/profile/15964361079720234778noreply@blogger.com