http://thediscoblog.com/2006/03/04/implementing-test-categorization/ Can you dig it man? Sat, 22 Nov 2008 06:13:00 +0000 http://wordpress.org/?v=2.6 http://thediscoblog.com/2006/03/04/implementing-test-categorization/#comment-1592 The Disco Blog » Ruby test categorization techniques Sat, 09 Sep 2006 17:52:35 +0000 http://thediscoblog.com/?p=19#comment-1592 [...] Much like pre-JUnit 4, Ruby’s copasetic Test::Unit framework lacks the easy ability to programmatically delineate a particular test’s grouping. Nevertheless, categorizing tests in Ruby is easy man– either through test case naming or directory segmentation. It also helps to use Ruby’s Rake build platform. [...] [...] Much like pre-JUnit 4, Ruby’s copasetic Test::Unit framework lacks the easy ability to programmatically delineate a particular test’s grouping. Nevertheless, categorizing tests in Ruby is easy man– either through test case naming or directory segmentation. It also helps to use Ruby’s Rake build platform. [...]

]]> http://thediscoblog.com/2006/03/04/implementing-test-categorization/#comment-25 The Disco Blog » Copasetic Coverage Frequencies Sun, 05 Mar 2006 15:00:48 +0000 http://thediscoblog.com/?p=19#comment-25 [...] If there are tripped out strategies for running tests at different intervals (which map to test categorization), it makes sense then to create an additional strategy where the coverage process is run once a day as part of each categorical test run. For example, every time the repository changes, the unit test process is run. At regular intervals throughout the day, component tests are executed and most likely, once a day (usually during the evening), system tests are run. After the system test process is run, another series of tests can be run where coverage is turned on (i.e. unit tests run against an instrumented code base, component tests run against an instrumented code base, and then system tests run against an instrumented code base). This process will create a series of reports which can then be viewed by the team the following morning. [...] [...] If there are tripped out strategies for running tests at different intervals (which map to test categorization), it makes sense then to create an additional strategy where the coverage process is run once a day as part of each categorical test run. For example, every time the repository changes, the unit test process is run. At regular intervals throughout the day, component tests are executed and most likely, once a day (usually during the evening), system tests are run. After the system test process is run, another series of tests can be run where coverage is turned on (i.e. unit tests run against an instrumented code base, component tests run against an instrumented code base, and then system tests run against an instrumented code base). This process will create a series of reports which can then be viewed by the team the following morning. [...]

]]>