[Kmymoney-devel] CSV Importer Plugin

[aga]

On Sunday 21 Feb 2010 23:02:15 Alvaro Soliverez wrote:
> On Sun, Feb 21, 2010 at 7:58 PM, aga <aganderson at ukonline.co.uk> wrote:
> > On Saturday 20 Feb 2010 16:10:11 Alvaro Soliverez wrote:
> >> On Sat, Feb 20, 2010 at 12:52 PM, aga <aganderson at ukonline.co.uk> wrote:
> >> > On Wednesday 17 Feb 2010 00:24:35 Alvaro Soliverez wrote:
> >> >> On Tue, Feb 16, 2010 at 8:31 PM, allan <aganderson at ukonline.co.uk> 
wrote:
> >> >> > On 16/02/10 17:42, Alvaro Soliverez wrote:
> >> >> >> On Tue, Feb 16, 2010 at 1:44 PM, allan <aganderson at ukonline.co.uk>
> >
> > wrote:
> >> >> >>> I realise you guys are up to your armpits, but I now have my
> >> >> >>> importer working in 3.96 (from tarball) and am wondering what
> >> >> >>> should happen next?
> >> >> >>>
> >> >> >>> The change involves an additional plugin folder and a one-line
> >> >> >>> addition to CMakeLists.txt in kmymoney/plugins/ .  I've tested it
> >> >> >>> with about 8-9 different institutions/formats/locale.
> >> >> >>>
> >> >> >>> The GUI allows for file selection, date format, file encoding
> >> >> >>> (although I've tended to concentrate on UTF-8), field delimiter
> >> >> >>> (',',  ';',  ':', 'tab').
> >> >> >>>
> >> >> >>> Then the fields 'number', 'date', 'payee/description',  and
> >> >> >>> 'amount' or 'debit' and 'credit' columns can be selected. Oh, and
> >> >> >>> a memo field allows multiple selection in case non-standard input
> >> >> >>> data needs to be collected.   Finally, the first and last lines
> >> >> >>> are specified, to allow for headers and trailers in the input
> >> >> >>> file. Then, either the data is imported into KMM, or dumped to
> >> >> >>> QIF file.
> >> >> >>>
> >> >> >>> Does anyone else have access to csv files to test further?  Also,
> >> >> >>> of course, someone will need to review it for glaring/gross
> >> >> >>> problem areas. In the mean time, I've some final tidying/ testing
> >> >> >>> to do.
> >> >> >>
> >> >> >> @Cristian,
> >> >> >> can you handle the review of this from the point of view of how to
> >> >> >> manage plugins?
> >> >> >> So that it is similar code-wise to the existing ones.
> >> >> >>
> >> >> >> @Allan,
> >> >> >> have you created unit tests for your code?
> >> >> >> For the non-GUI code, I mean.
> >> >> >>
> >> >> >> Regards,
> >> >> >> Alvaro
> >> >> >
> >> >> > Hi Alvaro
> >> >> >
> >> >> > Always wondered what they were!  Once I've finished the tidy-up,
> >> >> > I'll look into them.
> >> >> >
> >> >> > Hi Christian
> >> >> >
> >> >> > I'll drop a tarball to you once I've done.  I've borrowed a few
> >> >> > bits from here and there - the rest, I have to accept
> >> >> > responsibility for, so style-wise, well, I suppose willing amateur
> >> >> > covers it.
> >> >>
> >> >> Please post the patch to the list so everyone can chime in, although
> >> >> Cristian will do the main review.
> >> >> I'll take care of the nitpicking, and I'll assure you Thomas will see
> >> >> to it that you get unit tests in. :D
> >> >> _______________________________________________
> >> >
> >> > I've finished the tidy-up and pruning and have taken a quick look at
> >> > testing.
> >> >
> >> > I thought I'd try QTest, on the assumption that the end -result would
> >> > be a free-standing executable, so would not matter what the process
> >> > was. Would that be a major issue, or is it the end-result that counts?
> >>
> >> I would stick to using the cpp unit tests for now, since that's what
> >> we use for the rest, and that way we can run them all in one go.
> >> Actually, there is a nightly process that runs all tests and that way
> >> we know if we commited something that breaks.
> >>
> >> Eventually, we'll probably move to QTest or similar, so we can test the
> >> UI too.
> >>
> >> Regards,
> >> Alvaro
> >
> > Well, who'd have thought that???  After my usual teething troubles, I've
> > managed to make a start.  I've just implemented one test case so
> > far,......and, it found a bug.  Is that supposed to happen?
> >
> > I'm just slightly amazed.
> 
> Congratz!
> And yes, that's supposed to happen.
> It's the raison d'etre of the unit tests.
> First, to make sure you don't screw up when you first develop a
> feature, and then to make sure you don't screw up when you change
> something else. :D

Yes, I knew that really!  But, I certainly didn't expect it to happen first 
go.

Allan