 | |
#231
 
| |||
| |||
|
Re: In-memory PostgreSQL database -
05-26-2008
, 07:11 AM
|
No, I mean "every time any source file is changed in the working tree". There's a loop watching for filesystem events on the working tree the developer is working in, and executing the unit test suite whenever that happens. That way, the developer never needs to distract themselves distinguishing between "an edit that means I should run the unit test suite" versus "an edit that isn't worth running the unit test suite". The unit test suite is *always* run after an edit, and the developer can choose when to look at the results. Ouch. From my experience as a coder, you save code not only when you have an error-free or even compiling state. This means that the tests will be all red most of the time, and after some time, people will stop watching them at all. |
unit test will certainly be fixing it again. And more than likely before
any other commits. So he will receive pressure to get it done. I can't
see any pressure to ignore the failed test.
Quote:
|
Have you talked to your developers about that? You could have a unit test server that has a database server installed. Every 5 minutes it checks out the project source, initializes the database and runs the unit tests. This is also an excellent practice, and we follow it, but is more in line for an "integration" cycle: check out the current source code every time a commit is done, and attempt to build the entire project, making a report available on completion for anyone to check when they feel like. It's an altogether different purpose from unit testing, though. |
when the unit test starts you just create the ram disk, start the server,
run your default sql to setup the data, and your set. Cleanup is as
simple as stopping the server and dumping the ramdisk.
However, if speed is not an issue, I don't see why you have a problem with
just using the harddisk on a full postgresql server.
Besides, your trying to cheat anyway. You know for a proper unit test you
can't use a proper DB at all. You need to use some almost scripted
responses to SQL commands. You appear to be trying to avoid that. Once
you do, you might as well just run a full db...
CL
#232
| |||
| |||
|
|
No, I mean "every time any source file is changed in the working tree". There's a loop watching for filesystem events on the working tree the developer is working in, and executing the unit test suite whenever that happens. That way, the developer never needs to distract themselves distinguishing between "an edit that means I should run the unit test suite" versus "an edit that isn't worth running the unit test suite". The unit test suite is *always* run after an edit, and the developer can choose when to look at the results. Ouch. From my experience as a coder, you save code not only when you have an error-free or even compiling state. This means that the tests will be all red most of the time, and after some time, people will stop watching them at all. |
unit test will certainly be fixing it again. And more than likely before
any other commits. So he will receive pressure to get it done. I can't
see any pressure to ignore the failed test.
Quote:
|
Have you talked to your developers about that? You could have a unit test server that has a database server installed. Every 5 minutes it checks out the project source, initializes the database and runs the unit tests. This is also an excellent practice, and we follow it, but is more in line for an "integration" cycle: check out the current source code every time a commit is done, and attempt to build the entire project, making a report available on completion for anyone to check when they feel like. It's an altogether different purpose from unit testing, though. |
when the unit test starts you just create the ram disk, start the server,
run your default sql to setup the data, and your set. Cleanup is as
simple as stopping the server and dumping the ramdisk.
However, if speed is not an issue, I don't see why you have a problem with
just using the harddisk on a full postgresql server.
Besides, your trying to cheat anyway. You know for a proper unit test you
can't use a proper DB at all. You need to use some almost scripted
responses to SQL commands. You appear to be trying to avoid that. Once
you do, you might as well just run a full db...
CL
#233
| |||
| |||
|
|
No, I mean "every time any source file is changed in the working tree". There's a loop watching for filesystem events on the working tree the developer is working in, and executing the unit test suite whenever that happens. That way, the developer never needs to distract themselves distinguishing between "an edit that means I should run the unit test suite" versus "an edit that isn't worth running the unit test suite". The unit test suite is *always* run after an edit, and the developer can choose when to look at the results. Ouch. From my experience as a coder, you save code not only when you have an error-free or even compiling state. This means that the tests will be all red most of the time, and after some time, people will stop watching them at all. |
unit test will certainly be fixing it again. And more than likely before
any other commits. So he will receive pressure to get it done. I can't
see any pressure to ignore the failed test.
Quote:
|
Have you talked to your developers about that? You could have a unit test server that has a database server installed. Every 5 minutes it checks out the project source, initializes the database and runs the unit tests. This is also an excellent practice, and we follow it, but is more in line for an "integration" cycle: check out the current source code every time a commit is done, and attempt to build the entire project, making a report available on completion for anyone to check when they feel like. It's an altogether different purpose from unit testing, though. |
when the unit test starts you just create the ram disk, start the server,
run your default sql to setup the data, and your set. Cleanup is as
simple as stopping the server and dumping the ramdisk.
However, if speed is not an issue, I don't see why you have a problem with
just using the harddisk on a full postgresql server.
Besides, your trying to cheat anyway. You know for a proper unit test you
can't use a proper DB at all. You need to use some almost scripted
responses to SQL commands. You appear to be trying to avoid that. Once
you do, you might as well just run a full db...
CL
 |
« Previous Thread
|
Next Thread »
| Thread Tools | |
| Display Modes | |
Linear Mode
| |
Powered by vBulletin Version 3.5.3
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.