Operation refactor (part 1)

[giannissc]

I am introducing Tool and Spindle changes to the Fluent API and all the necessary tests

In Part 2 I will be introducing Feed changes. This is going to be messier so I opted for breaking them into 2 PR.

[codecov]

Codecov Report

Merging #37 (1c3c53e) into unstable (4cd6fa6) will increase coverage by 1.36%.
The diff coverage is 99.24%.

❗ Current head 1c3c53e differs from pull request most recent head 1cb1784. Consider uploading reports for the commit 1cb1784 to get more accurate results

@@             Coverage Diff              @@
##           unstable      #37      +/-   ##
============================================
+ Coverage     81.76%   83.13%   +1.36%     
============================================
  Files            34       36       +2     
  Lines          2462     2567     +105     
============================================
+ Hits           2013     2134     +121     
+ Misses          449      433      -16     

Impacted Files	Coverage Δ
src/cq_cam/common.py	100.00% <ø> (ø)
src/cq_cam/operations/base_operation.py	78.33% <ø> (ø)
src/cq_cam/fluent.py	87.19% <96.42%> (+3.13%)	⬆️
src/cq_cam/command.py	86.72% <100.00%> (+0.19%)	⬆️
src/cq_cam/tests/conftest.py	100.00% <100.00%> (ø)
src/cq_cam/tests/test_drill.py	100.00% <100.00%> (ø)
src/cq_cam/tests/test_gcode.py	100.00% <100.00%> (ø)
src/cq_cam/tests/test_pocket.py	100.00% <100.00%> (ø)
src/cq_cam/tests/test_profile.py	100.00% <100.00%> (ø)
src/cq_cam/tests/test_tool_change.py	100.00% <100.00%> (ø)
... and 1 more

... and 3 files with indirect coverage changes

[giannissc]

SonarCloud is raising duplication errors on the test strings. Should I try to fix? @voneiden

[voneiden]

The duplication errors are for the four last tests which share a very similar structure. If you want to get your hands dirty, check out parametrization @ https://docs.pytest.org/en/6.2.x/parametrize.html

You could parametrize the tool(s) and expected outputs and have a single test.

The test string code smell nags are because there are no line breaks but the strings are broken into multiple string sections, like

x = ("foo" "bar")

vs

x = ("foo"
     "bar")

It's also not necessary to always test full gcode output - in fact testing only within the scope of the test would be preferable in this case. Makes the test less fragile to noise.

[giannissc]

The test string is modified by black so If I add the line then black check will fail

[giannissc]

Can I parametrize across test files. test_pocket, test_profile and test_drill they same the exact same thing. The operation that happens is irrelevant since we are just checking what gets added between operation. Where should I include such a test? A new test_tool_change file? @voneiden

[voneiden]

My bad. Maybe that can be resolved by adding a comment on the first line, then black shouldn't be able to touch the line breaks:

x = (
    # black
    "foo"
    "bar"
)

L

[voneiden]

New file is fine and perhaps the operation can be one parameter of the test.

[sonarcloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
0.0% Duplication

[sonarcloud]

Please retry analysis of this Pull-Request directly on SonarCloud.

[giannissc]

Ready! @voneiden

[voneiden]

Looks good, thank you.