[Kmymoney-devel] CSV Importer Plugin

[Alvaro Soliverez]

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