it sounds great in theory but may be easier said than done. at the very least the route from TrafficOpsRoutes.pm should be deleted when rewritten in Go. should the handler and all the functions used by the handler be deleted as well? like dan said, that may be a messy effort with a high level of risk as our perl tests are crumbling so you'll really have no idea what you potentially broke.
just my 2 cents. of course i'm in favor of removing dead code whenever possible (depending on the effort / risk level). and yes, i strongly agree with Dave that the rewrite of the api should be a good opportunity to write valuable tests. I look at it this way. If you want something to continue working, write tests. if you don't care, don't write tests. :) jeremy On Wed, Jun 20, 2018 at 3:34 PM, Dave Neuman <neu...@apache.org> wrote: > +1 on removing dead code. > I think I am mostly in agreement with Rob, I think we should remove the > dead code and delete the Perl tests that break as a result. In my opinion > the tests aren't very useful as they are pretty fagile (hard-coded array > numbers) and aren't doing that much validation anyway. If we can come up > with a reasonable way to replace a perl test with a test in golang that > exercises the Perl API then we should attempt to do it. As we re-write > endpoints in go, we should make sure that we write useful tests using the > testing framework including writing whatever needs to be written in the > golang client to support the test. > > Thanks, > Dave > > > On Wed, Jun 20, 2018 at 10:50 AM Dan Kirkwood <dang...@gmail.com> wrote: > > > I'm all for #3. In fact, the `traffic_ops/testing/api` framework that > > Dewayne has developed encourages testing from the HTTP calls (which you > > suggest in #1). That covers the endpoint no matter how it's implemented. > > > > Removing dead Perl code can be tricky, since the interdependencies are > not > > always obvious, and can lead to unforeseen missing functionality. TO > uses > > dynamic addition of methods to objects. The Mojolicious framework, in > > fact, encourages this. I'm in favor of getting better testing in place > > that covers existing endpoints no matter where they fall. As the Go code > > progresses, remove the endpoints from Perl (but not the supporting code) > > and remove tests as they are added on the Go side. Remove the whole > Perl > > code once the Go code is complete. > > > > -dan > > > > 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 > > > > > > > > > >
