5 ms·

We do have a CI server, and as you said it works well for catching failing tests. However, it requires that you commit and push your changes in order to test th

by jamis 16y ago

We do have a CI server, and as you said it works well for catching failing tests. However, it requires that you commit and push your changes in order to test them, which means you are effectively publishing untested changes to your entire team. The same for any kind of distributed testing, unless you are using a shared volume to host your sandbox. I'm running a Mac Pro with 8 cores, so there is a fair bit of parallelization I can do locally too. Unfortunately, the tests all depend on the database, and while I can certainly use tools like deep-test to spin up separate DB's for each worker, I've found that doing so adds a full 60 seconds to the test run. I fear that until we eliminate the database from (most of) our tests, super-fast runs will continue to elude us. CI and distributed tests are good things, no question, but I'm still looking for ways to make it possible to run my tests locally in TDD-fashion. I'm far from out of ideas, it's just a matter of making time to experiment.

patio11 16y ago
This is totally a personal/team comfort question, but is there any reason why you can't have two remotes? "git push jamistest" might use a few bits on a spinning platter somewhere, but that is cheap, and there is no reason your team has to see it if you don't push it to the master repo, any more than they see changes you keep on your local repo.
- jamis 16y ago
  Aside from me simply wanting to be able to quickly run my tests locally, you mean? :) Mostly it's just an issue of configuring that so it works for all the programmers. Each would need their own remote, and each would need to be hooked into CI. Definitely possible, it just hasn't been a priority.
xentronium 16y ago
Most of the time you need only some of your tests (the ones you're working on currently). Then, preloading the framework becomes the real bottleneck. But it's solvable too, via spork (I believe, there is spork-testunit, but I never tried it). Most of my coding is done in minute loops (add test / watch tests fail / add couple of lines / watch tests succeed). YMMV.
- aaronblohowiak 16y ago
  spork is friggen awesome, and if you are on MRI/Yarv you really should use it. http://spork.rubyforge.org/ http://spork.rubyforge.org/
gnufied 16y ago
Hey Jamis, Your CI server should be able to accept a patchset and run it without committing it. TeamCity does this (or roll your own CI server can do this too!).

by jamis 16y ago

patio11 16y ago

This is totally a personal/team comfort question, but is there any reason why you can't have two remotes? "git push jamistest" might use a few bits on a spinning platter somewhere, but that is cheap, and there is no reason your team has to see it if you don't push it to the master repo, any more than they see changes you keep on your local repo.

jamis 16y ago
Aside from me simply wanting to be able to quickly run my tests locally, you mean? :) Mostly it's just an issue of configuring that so it works for all the programmers. Each would need their own remote, and each would need to be hooked into CI. Definitely possible, it just hasn't been a priority.

xentronium 16y ago

Most of the time you need only some of your tests (the ones you're working on currently). Then, preloading the framework becomes the real bottleneck. But it's solvable too, via spork (I believe, there is spork-testunit, but I never tried it). Most of my coding is done in minute loops (add test / watch tests fail / add couple of lines / watch tests succeed). YMMV.

aaronblohowiak 16y ago
spork is friggen awesome, and if you are on MRI/Yarv you really should use it. http://spork.rubyforge.org/ http://spork.rubyforge.org/

gnufied 16y ago

Hey Jamis, Your CI server should be able to accept a patchset and run it without committing it. TeamCity does this (or roll your own CI server can do this too!).