+1 on removing dead code. IMO the danger and cost of the dead code far outweighs the benefit of the Perl tests. Especially considering AFAIK most of the tests are just verifying the response is a 200, not actually checking the body or database or validating anything.
We just had someone in the community write code, for the second time, in old dead Perl that's never called. We're wasting people's time, dangers and bugs aside. I vote we remove the dead code ASAP, and then worry about adding more, useful tests. >#1 is pretty hard / not feasible. I believe Dewayne already looked into that >#2 sounds hard and probably work that would just be wasted imo > #3 i like this idea. let's pretend we have 100 API tests in perl. rewrite >all 100 to Go, delete the perl tests entirely. this is also a good idea >because it provides somewhat of a safety net for the perl to Go api rewrite >which i don't think exists currently. 2 sounds a lot easier than 3 to me. I agree completely, we need to write "API Tests" for all the Go endpoints. But the "API Test" framework takes a lot of time, in my experience, to work with. It doesn't support a lot of things (like Riak). In the past, when I've converted an endpoint, frequently the framework hasn't supported all the tables it's hit, or external resources, or some combination, and it's required significant work to extend. Further, the "API Test" framework uses the Go client, which is missing a huge number of endpoints. Which means writing tests for endpoints requires additionally writing client functions. Extending the client is good, but it's more time, and delays the Go rewrite project. Yes, 2 would be "wasted" in the long term, but I suspect it's far less work for each endpoint, to replace calls to removed endpoints/tests with mock data. I could be wrong, I haven't investigated thoroughly, but I'm hoping to look into it more shortly. I'm not convinced 1 is infeasible either. It seems like the kind of thing that could appear difficult/impossible until you stumble on the one magic way to make it work. It might be worth another person or two independently investigating, to see if someone stumbles across the magic way to do it. But again, my vote would be to delete the dead Perl code now, delete tests that break, that arguably aren't very useful anyway, and write new "API Tests" as we go, and devote our development time to getting the rewrite done. It's a huge task, and every hour we devote to maintaining the old minimally-useful Perl tests is that much longer before the project is done. But if there's consensus that we can't do that, I vote we do whatever is the least work, and I suspect that's #2. On Wed, Jun 20, 2018 at 10:18 AM, Jeremy Mitchell <mitchell...@gmail.com> wrote: > #1 is pretty hard / not feasible. I believe Dewayne already looked into > that > #2 sounds hard and probably work that would just be wasted imo > #3 i like this idea. let's pretend we have 100 API tests in perl. rewrite > all 100 to Go, delete the perl tests entirely. this is also a good idea > because it provides somewhat of a safety net for the perl to Go api rewrite > which i don't think exists currently. > > Jeremy > > On Wed, Jun 20, 2018 at 9:54 AM, Rawlin Peters <rawlin.pet...@gmail.com> > wrote: > > > Hey Traffic Controllers, > > > > In order to accelerate our progress toward using and developing > > traffic_ops_golang as a community, I'd like to propose that we remove > > all of the dead Perl Traffic Ops API code in the repo. Many endpoints > > have been rewritten in Go at this point, and by keeping the obsolete > > Perl endpoints in the repo we're not making it clear that new > > enhancements have to be made in traffic_ops_golang and Traffic Portal > > in order to actually work and survive long-term (as opposed to the > > legacy Perl Traffic Ops API and UI which is planned to be deprecated > > and removed in the near future). > > > > Right now the only thing keeping the dead Perl endpoints from being > > deleted is the Perl test framework that depends on them. Unfortunately > > the tests are all caught in a spider web of interdependency, so we > > can't simply remove tests for APIs that have been rewritten in Go > > without breaking other tests. However, we think there are a few ways > > we should be able to accomplish this: > > > > 1. Make the Perl integration tests actually make HTTP calls which can > > then be handled by traffic_ops_golang, rather than calling the Perl > > API router directly. > > 2. Remove test interdependencies by mocking out the test data. > > 3. Rewrite all the Perl tests in the go API test framework and remove > > the Perl tests. > > > > We are also open to other suggestions that allow us to remove dead Perl > > code :). > > > > Please +1 or -1 if you agree or disagree; all feedback is welcome. > > > > - Rawlin > > >
