5 ms·

My favorite resource for learning how to test your code is http://getpython3.com/diveintopython3/unit-testing.html http://getpython3.com/diveintopython3/unit-te

My favorite resource for learning how to test your code is http://getpython3.com/diveintopython3/unit-testing.html http://getpython3.com/diveintopython3/unit-testing.html Once you start testing your code, it's addictive. Testing gives you confidence. - By forcing you to detail your requirements, writing tests helps you make sure that you're building the right thing. - Testing lets you refactor your code with confidence -- if your old tests still pass after you refactor, your new version works the same way as your old version. - Testing makes your code much (MUCH!) more maintainable. As long as your old tests still pass, you can be confident that the new code you wrote didn't break any of your old code.

pravj 12y ago
Yeah, addictive it is. I remember last year contributing[1] to a 2048 python game, where the maintainer committed[2] test suite lengthy than my commit and He was doing it like a charm. I think I should start from that very repository as I know it very well already. 1. https://github.com/bfontaine/term2048/commits?author=pravj https://github.com/bfontaine/term2048/commits?author=pravj 2. https://github.com/bfontaine/term2048/commit/6f9a46283c2cc0a2bf105f3e899e3f127d62610b https://github.com/bfontaine/term2048/commit/6f9a46283c2cc0a...
- abecedarius 12y ago
  That looks good. For counterpoint, here is my 2048 including tests for just the tricky bit: https://github.com/darius/sturm/blob/master/2048.py https://github.com/darius/sturm/blob/master/2048.py I have Emacs set up to run them on a keypress without even having to save the file; you can create and run these tests even quicker than trying things out in a REPL, and unlike the REPL they persist to be rerun after the next change. If you've been feeling like testing is too much work, one angle is to reduce the amount of work it'll take to start.
foobarian 12y ago
I've been writing Python unit tests lately too. I stick all the tests in files named test_.....py, have a top level file run-tests.py that runs them all, and then (this on Ubuntu): watch -n 0.1 ./run-tests.py in a window on the side. Then I can go off and change stuff and as soon as something breaks I see it in the side window. If I break something and the tests don't break, well, time to write more tests :-)

pravj 12y ago

Yeah, addictive it is. I remember last year contributing[1] to a 2048 python game, where the maintainer committed[2] test suite lengthy than my commit and He was doing it like a charm. I think I should start from that very repository as I know it very well already. 1. https://github.com/bfontaine/term2048/commits?author=pravj https://github.com/bfontaine/term2048/commits?author=pravj 2. https://github.com/bfontaine/term2048/commit/6f9a46283c2cc0a2bf105f3e899e3f127d62610b https://github.com/bfontaine/term2048/commit/6f9a46283c2cc0a...

abecedarius 12y ago
That looks good. For counterpoint, here is my 2048 including tests for just the tricky bit: https://github.com/darius/sturm/blob/master/2048.py https://github.com/darius/sturm/blob/master/2048.py I have Emacs set up to run them on a keypress without even having to save the file; you can create and run these tests even quicker than trying things out in a REPL, and unlike the REPL they persist to be rerun after the next change. If you've been feeling like testing is too much work, one angle is to reduce the amount of work it'll take to start.

foobarian 12y ago

I've been writing Python unit tests lately too. I stick all the tests in files named test_.....py, have a top level file run-tests.py that runs them all, and then (this on Ubuntu): watch -n 0.1 ./run-tests.py in a window on the side. Then I can go off and change stuff and as soon as something breaks I see it in the side window. If I break something and the tests don't break, well, time to write more tests :-)