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 > > >
