Project Testing

web.mit.edu · 693 words · saved by 1 readers

Starting with Problem Set 0, you have been using the Didit system for automated building and testing: every time you push your commits to GitHub, the Didit build server pulls a copy of your code, attempts to compile it, and runs tests. This kind of automation is very common in the world of professional software development, and is very useful for coordinating a team of developers. There is no ambiguity about whether the code compiles or not: if it doesn’t compile on the build server, it doesn’t compile. And there is no ambiguity about whether the tests pass: if they don’t pass on the build server, they don’t pass. You may not use packages other than those included in the provided package.json. Your tests must not use unreasonable amounts of space (e.g. large images) or time (e.g. slow concurrency tests). Your code should use localhost ports 8700—8799 to communicate between servers and clients. As always, do not attempt to run anything other than your project tests. You may have some te

Project Testing Project Testing Automated Testing Starting with Problem Set 0, you have been using the Didit system for automated building and testing: every time you push your commits to GitHub, the Didit build server pulls a copy of your code, attempts to compile it, and runs tests. This kind of automation is very common in the world of professional software development, and is very useful for coordinating a team of developers. There is no ambiguity about whether the code compiles or not: if it doesn’t compile on the build server, it doesn’t compile. And there is no ambiguity about whether t

Project Testing

related reading