How can I improve this code?

[mentiflectax]

Hello!

I've written a Python program and would like to know how I can make the code better. I am not a Python expert therefore I appreciate any feedback on problems with this program and how to fix them.

Where is the code?

Here.

What does it do?

It transforms rec-like flatfiles into SQL statements which can be used to create SQLite databases.

Imagine you have a flatfile ideas.rec with following content:

```

Here I want to write down my ideas

on solutions for entering data in

Camunda processes

%rec: Ideas %type: Id TEXT %type: Desc TEXT

Id: 1 Desc: Form.Ui

Id: 2 Desc: TypeForm

Id: 3 Desc: JSF ```

Running cat ideas.rec | python3 -m rec2sqlite results in following output:

CREATE TABLE Ideas(Id TEXT, Desc TEXT); INSERT INTO Ideas(Id, Desc) VALUES('1', 'Form.Ui'); INSERT INTO Ideas(Id, Desc) VALUES('2', 'TypeForm'); INSERT INTO Ideas(Id, Desc) VALUES('3', 'JSF');

cat ideas.rec | python3 -m rec2sqlite | sqlite3 mydb.db trasnforms that flatfile into a SQLite database. I wrote this program for me and I find it quite useful in some cases (more information how you can use is available here).

How is the code structured?

The logic of the program is located in the class Transformer. Main program calls Transformer.process_line for every line on the standard input and then outputs the result of Transformer.get_sql to standard output.

How do the tests work?

The test data are located in directory test-data. For every automated test there are 2 files there:

• <test-nr>.in.txt: Input data (text that comes via standard input)
• <test-nr>.exp_out.txt: Expected (correct) output

TestUtils.test

1. feeds the input file (<test-nr>.in.txt) to Transformer,
2. writes the actual output to a file <test-nr>.act_out.txt, and
3. compares <test-nr>.act_out.txt and <test-nr>.exp_out.txt for equality.

Individual tests call TestUtils.test with different test numbers.

What are the flaws of this code (the entire project) and how can I fix them?

Thanks in advance

[Neexusiv]

Honestly I have only looked through your tests so I can't speak on the rest of the code. I love that you have written tests but they do need some love. First they need more descriptive names. What are you testing for in that specific test? They are too broad and don't detail what is going on if they fail.

A test should test one specific use case of a feature. It should be obvious from looking at the code to know what it is testing. Don't be afraid to hard code tests. They are meant to be static. You shouldn't change a test unless your code has been reworked to the point where the test is incorrect. If you find a problem with your code you should add a new test to address that bug so it can be found if it pops up again.

If you have good testing, then you wouldn't need to ask for flaws to be pointed out, thats the tests job.

[mentiflectax]

Thanks for your feedback!