4 ms·
I haven't heard about people writing some sort of scripts to run "against" the real code. Most people do manual integration testing by running the application,
by nawitus 12y ago
I haven't heard about people writing some sort of scripts to run "against" the real code. Most people do manual integration testing by running the application, and doing some light debugging, and then when it starts to work, write a few tests (if any).
- taeric 12y agoImagine if they could codify their manual integration tests in such a way that they could be automated? Not necessarily a unit test, but still a test. Likely a valuable one.
- nawitus 12y agoYes, obviously we do that, but after the feature is working. It's not practical to write it before implementing it at least with the stack I'm working on currently. We use Selenium+Protractor for integration tests, and these tests are implementation specific.
- pessimizer 12y agoI do it, except they're not scripts, but really high level functions and objects/processes that create and delete themselves. And although I'm not explicitly TDD at all, those functions often end up becoming tests (or informing test writing) by production time. Applications I write are ultimately experiments in the interop of N different libraries that I haven't used in quite this combination before, so the first code I write is usually checking to see if things will work in combination in the way that I think they will. That involves writing code that has the stripped down functionality of the parts of the design that I thought could benefit by using those libraries. The last thing I finalize is the highest level logic, and by the time I write it, I know it's going to work.