Comments on: Four ways of handling Givens http://lizkeogh.com/2008/11/18/four-ways-of-handling-givens/ Software, Training, Coaching, Writing Wed, 08 Feb 2012 12:59:05 -0500 http://wordpress.org/?v=2.8.6 hourly 1 By: liz http://lizkeogh.com/2008/11/18/four-ways-of-handling-givens/comment-page-1/#comment-1284 liz Wed, 19 Nov 2008 11:13:49 +0000 http://lizkeogh.com/?p=389#comment-1284 Kris, absolutely. I believe every developer should test things manually anyway, even if we don't have an automated test. It helps me understand what my user will be doing and how they'll use my code, and stops me worrying about ways they might break my system when they don't have a mechanism to do so. We're programming the Game of Life at the moment, and some of the developers here were writing acceptance tests to show what happens if cells are born outside of the grid. As soon as we persuaded them to launch the application, they realised that there was nothing for the users to actually click on, so creating cells outside of the grid was impossible. Therefore they had no way to make the scenarios even happen, let alone pass. I love the feedback that my GUI gives me! Kris, absolutely. I believe every developer should test things manually anyway, even if we don’t have an automated test. It helps me understand what my user will be doing and how they’ll use my code, and stops me worrying about ways they might break my system when they don’t have a mechanism to do so.

We’re programming the Game of Life at the moment, and some of the developers here were writing acceptance tests to show what happens if cells are born outside of the grid. As soon as we persuaded them to launch the application, they realised that there was nothing for the users to actually click on, so creating cells outside of the grid was impossible. Therefore they had no way to make the scenarios even happen, let alone pass.

I love the feedback that my GUI gives me!

]]> By: Kris Kemper http://lizkeogh.com/2008/11/18/four-ways-of-handling-givens/comment-page-1/#comment-1283 Kris Kemper Wed, 19 Nov 2008 03:33:07 +0000 http://lizkeogh.com/?p=389#comment-1283 Of the approaches that you presented, the one where you setup the state directly is the easiest in terms of automating a test. Nonetheless, Any of the 4 approaches is good for testing the functionality manually, and as much as it might hurt some people to test something manually, every developer should do it if they can't get an automated test out in a reasonable time. It's a common mistake I've seen - hoping that the feature works, only to find out later in the QA cycle that it doesn't. Every developer should QA there own features just like the QA would, preferably with an automated test, but manually if needed. Of the approaches that you presented, the one where you setup the state directly is the easiest in terms of automating a test. Nonetheless, Any of the 4 approaches is good for testing the functionality manually, and as much as it might hurt some people to test something manually, every developer should do it if they can’t get an automated test out in a reasonable time. It’s a common mistake I’ve seen – hoping that the feature works, only to find out later in the QA cycle that it doesn’t. Every developer should QA there own features just like the QA would, preferably with an automated test, but manually if needed.

]]>