Re: [Koha-devel] Advice for testing bug 17710
I suppose in this case I rather be told what’s enough than doing my best and being told it’s not enough. I suppose we’re all time poor, but I don’t have 100% time on Koha anymore. Test::MockModule might work. Long term, it probably makes more sense to refactor get_matches, but I think it could work for now to show that the code I’m using works. Although in that case, should I put my sorting code as a function or copy and paste from the module into the test? I suppose any time a person says copy and paste, the answer is make a function… What do you mean by keep in touch with QA members? David Cook Systems Librarian Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Direct: 02 8005 0595 From: Tomas Cohen Arazi [mailto:tomascohen@gmail.com] Sent: Thursday, 12 January 2017 11:56 AM To: David Cook <dcook@prosentient.com.au> Subject: Re: [Koha-devel] Advice for testing bug 17710 David, do your best and try to keep in touch with QA members. While we enforce the introduction of regression tests, there are exceptions. We usually get grumpy when tests are trivial, and we deduce laziness on the developer side. El mié., 11 de ene. de 2017 9:33 PM, David Cook <dcook@prosentient.com.au <mailto:dcook@prosentient.com.au> > escribió: Hi all, I wrote a little patch to make C4::Matcher::get_matches and C4::ImportBatch::GetBestRecordMatch use the same logic for sorting matches, so that matches are returned consistently in the same order. However, C4::Matcher::get_matches is basically spaghetti and relies on Zebra (and a hard-coded Zebra server at that), so I’m not sure how best to test it. I was thinking maybe turning the sorting into a little function and unit testing that. Would that be sufficient? In terms of manual testing, I think matching is mostly done behind the scenes, so it would be tough to verify the output of the sort… David Cook Systems Librarian Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Direct: 02 8005 0595 _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org <mailto:Koha-devel@lists.koha-community.org> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/ -- Tomás Cohen Arazi Theke Solutions (https://theke.io <http://theke.io/> ) ✆ +54 9351 3513384 GPG: B2F3C15F
El jue., 12 ene. 2017 a las 0:54, David Cook (<dcook@prosentient.com.au>) escribió:
I suppose in this case I rather be told what’s enough than doing my best and being told it’s not enough. I suppose we’re all time poor, but I don’t have 100% time on Koha anymore.
I guess there's no straight answer. It will depend on signoffers and QA people's opinion. People tend to focus on the stuff they care, lately, so that's why I said...
Test::MockModule might work. Long term, it probably makes more sense to refactor get_matches, but I think it could work for now to show that the code I’m using works. Although in that case, should I put my sorting code as a function or copy and paste from the module into the test? I suppose any time a person says copy and paste, the answer is make a function…
What do you mean by keep in touch with QA members?
... you should keep in touch with people that might have interest in helping you get your patches in. Sometimes people just drop some patches and wait for others to care about them. And it doesn't work like that most of the time. Keeping in touch means contacting them, explain things, ask for feedback on specific edges. When you write patches for complicated stuff that doesn't have prior tests, your best bet is to mock most of the context so you can create the desired scenario. That's what I did with Auth_with_ldap.t at some point. It was even fun to write. -- Tomás Cohen Arazi Theke Solutions (https://theke.io <http://theke.io/>) ✆ +54 9351 3513384 GPG: B2F3C15F
participants (2)
-
David Cook -
Tomas Cohen Arazi