Move test suite to pytest #1335
Conversation
![sourcery-ai[bot]](https://avatars.githubusercontent.com/in/48477?s=60&v=4){kind=small}
There was a problem hiding this comment.
We've reviewed this pull request using the Sourcery rules engine. If you would also like our AI-powered code review then let us know.
| for ed in t.edges(): | ||
| is_bezier, bezier_curve, degree = edge_to_bezier(ed) | ||
| assert isinstance(is_bezier, bool) | ||
| if not is_bezier: | ||
| assert degree is None | ||
| assert bezier_curve is None | ||
| else: | ||
| assert isinstance(degree, int) |
There was a problem hiding this comment.
issue (code-quality): Avoid loops in tests. (no-loop-in-tests)
Explanation
Avoid complex code, like loops, in test functions.Google's software engineering guidelines says:
"Clear tests are trivially correct upon inspection"
To reach that avoid complex code in tests:
- loops
- conditionals
Some ways to fix this:
- Use parametrized tests to get rid of the loop.
- Move the complex logic into helpers.
- Move the complex part into pytest fixtures.
Complexity is most often introduced in the form of logic. Logic is defined via the imperative parts of programming languages such as operators, loops, and conditionals. When a piece of code contains logic, you need to do a bit of mental computation to determine its result instead of just reading it off of the screen. It doesn't take much logic to make a test more difficult to reason about.
Software Engineering at Google / Don't Put Logic in Tests
| if not is_bezier: | ||
| assert degree is None | ||
| assert bezier_curve is None | ||
| else: | ||
| assert isinstance(degree, int) |
There was a problem hiding this comment.
issue (code-quality): Avoid conditionals in tests. (no-conditionals-in-tests)
Explanation
Avoid complex code, like conditionals, in test functions.Google's software engineering guidelines says:
"Clear tests are trivially correct upon inspection"
To reach that avoid complex code in tests:
- loops
- conditionals
Some ways to fix this:
- Use parametrized tests to get rid of the loop.
- Move the complex logic into helpers.
- Move the complex part into pytest fixtures.
Complexity is most often introduced in the form of logic. Logic is defined via the imperative parts of programming languages such as operators, loops, and conditionals. When a piece of code contains logic, you need to do a bit of mental computation to determine its result instead of just reading it off of the screen. It doesn't take much logic to make a test more difficult to reason about.
Software Engineering at Google / Don't Put Logic in Tests
| for edge in topo.edges(): | ||
| pnts = discretize_edge(edge) | ||
| assert pnts |
There was a problem hiding this comment.
issue (code-quality): Avoid loops in tests. (no-loop-in-tests)
Explanation
Avoid complex code, like loops, in test functions.Google's software engineering guidelines says:
"Clear tests are trivially correct upon inspection"
To reach that avoid complex code in tests:
- loops
- conditionals
Some ways to fix this:
- Use parametrized tests to get rid of the loop.
- Move the complex logic into helpers.
- Move the complex part into pytest fixtures.
Complexity is most often introduced in the form of logic. Logic is defined via the imperative parts of programming languages such as operators, loops, and conditionals. When a piece of code contains logic, you need to do a bit of mental computation to determine its result instead of just reading it off of the screen. It doesn't take much logic to make a test more difficult to reason about.
Software Engineering at Google / Don't Put Logic in Tests
| for wire in topo.wires(): | ||
| pnts = discretize_wire(wire) | ||
| assert pnts |
There was a problem hiding this comment.
issue (code-quality): Avoid loops in tests. (no-loop-in-tests)
Explanation
Avoid complex code, like loops, in test functions.Google's software engineering guidelines says:
"Clear tests are trivially correct upon inspection"
To reach that avoid complex code in tests:
- loops
- conditionals
Some ways to fix this:
- Use parametrized tests to get rid of the loop.
- Move the complex logic into helpers.
- Move the complex part into pytest fixtures.
Complexity is most often introduced in the form of logic. Logic is defined via the imperative parts of programming languages such as operators, loops, and conditionals. When a piece of code contains logic, you need to do a bit of mental computation to determine its result instead of just reading it off of the screen. It doesn't take much logic to make a test more difficult to reason about.
Software Engineering at Google / Don't Put Logic in Tests
| for face in topo.faces(): | ||
| i += 1 | ||
| assert isinstance(face, TopoDS_Face) |
There was a problem hiding this comment.
issue (code-quality): Avoid loops in tests. (no-loop-in-tests)
Explanation
Avoid complex code, like loops, in test functions.Google's software engineering guidelines says:
"Clear tests are trivially correct upon inspection"
To reach that avoid complex code in tests:
- loops
- conditionals
Some ways to fix this:
- Use parametrized tests to get rid of the loop.
- Move the complex logic into helpers.
- Move the complex part into pytest fixtures.
Complexity is most often introduced in the form of logic. Logic is defined via the imperative parts of programming languages such as operators, loops, and conditionals. When a piece of code contains logic, you need to do a bit of mental computation to determine its result instead of just reading it off of the screen. It doesn't take much logic to make a test more difficult to reason about.
Software Engineering at Google / Don't Put Logic in Tests
test/test_core_geometry.py
Outdated
|
|
||
| QC = gccent.Outside(C) | ||
| P4 = gp_Pnt2d(-2, 7) | ||
| P5 = gp_Pnt2d(12, -3) | ||
| L = GccAna_Lin2d2Tan(P4, P5, precision.Confusion()).ThisSolution(1) | ||
|
|
||
| QL = gccent.Unqualified(L) | ||
| radius = 2.0 | ||
| TR = GccAna_Circ2d2TanRad(QC, QL, radius, precision.Confusion()) | ||
|
|
||
| if TR.IsDone(): | ||
| NbSol = TR.NbSolutions() | ||
| for k in range(1, NbSol + 1): | ||
| circ = TR.ThisSolution(k) | ||
| # find the solution circle | ||
| pnt1 = gp_Pnt2d() | ||
| parsol, pararg = TR.Tangency1(k, pnt1) | ||
| self.assertGreater(parsol, 0.0) | ||
| self.assertGreater(pararg, 0.0) | ||
| # find the first tangent point | ||
| pnt2 = gp_Pnt2d() | ||
| parsol, pararg = TR.Tangency2(k, pnt2) | ||
| self.assertGreater(parsol, 0.0) | ||
| self.assertGreater(pararg, 0.0) | ||
| # find the second tangent point | ||
|
|
||
| aLine = GCE2d_MakeSegment(L, -2, 20).Value() | ||
| self.assertIsInstance(aLine, Geom2d_TrimmedCurve) | ||
| if TR.IsDone(): | ||
| NbSol = TR.NbSolutions() | ||
| for k in range(1, NbSol + 1): | ||
| circ = TR.ThisSolution(k) | ||
| aCircle = Geom2d_Circle(circ) | ||
| self.assertIsInstance(aCircle, Geom2d_Circle) | ||
| # find the solution circle (index, outvalue, outvalue, gp_Pnt2d) | ||
| pnt3 = gp_Pnt2d() | ||
| parsol, pararg = TR.Tangency1(k, pnt3) | ||
| self.assertGreater(parsol, 0.0) | ||
| self.assertGreater(pararg, 0.0) | ||
| # find the first tangent point | ||
| pnt4 = gp_Pnt2d() | ||
| parsol, pararg = TR.Tangency2(k, pnt4) | ||
| self.assertGreater(parsol, 0.0) | ||
| self.assertGreater(pararg, 0.0) | ||
|
|
||
| def test_surface_from_curves(self): | ||
| """Test: surfaces from curves""" | ||
| array = [gp_Pnt(-4, 0, 2)] | ||
| array.append(gp_Pnt(-7, 2, 2)) | ||
| array.append(gp_Pnt(-6, 3, 1)) | ||
| array.append(gp_Pnt(-4, 3, -1)) | ||
| array.append(gp_Pnt(-3, 5, -2)) | ||
|
|
||
| aaa = point_list_to_TColgp_Array1OfPnt(array) | ||
| SPL1 = GeomAPI_PointsToBSpline(aaa).Curve() | ||
|
|
||
| a2 = [gp_Pnt(-4, 0, 2)] | ||
| a2.append(gp_Pnt(-2, 2, 0)) | ||
| a2.append(gp_Pnt(2, 3, -1)) | ||
| a2.append(gp_Pnt(3, 7, -2)) | ||
| a2.append(gp_Pnt(4, 9, -1)) | ||
| bbb = point_list_to_TColgp_Array1OfPnt(a2) | ||
| SPL2 = GeomAPI_PointsToBSpline(bbb).Curve() | ||
|
|
||
| aGeomFill1 = GeomFill_BSplineCurves(SPL1, SPL2, GeomFill_StretchStyle) | ||
|
|
||
| SPL3 = Geom_BSplineCurve.DownCast(SPL1.Translated(gp_Vec(10, 0, 0))) | ||
| SPL4 = Geom_BSplineCurve.DownCast(SPL2.Translated(gp_Vec(10, 0, 0))) | ||
| aGeomFill2 = GeomFill_BSplineCurves(SPL3, SPL4, GeomFill_CoonsStyle) | ||
|
|
||
| SPL5 = Geom_BSplineCurve.DownCast(SPL1.Translated(gp_Vec(20, 0, 0))) | ||
| SPL6 = Geom_BSplineCurve.DownCast(SPL2.Translated(gp_Vec(20, 0, 0))) | ||
| aGeomFill3 = GeomFill_BSplineCurves(SPL5, SPL6, GeomFill_CurvedStyle) | ||
|
|
||
| aBSplineSurface1 = aGeomFill1.Surface() | ||
| self.assertTrue(aBSplineSurface1 is not None) | ||
| aBSplineSurface2 = aGeomFill2.Surface() | ||
| self.assertTrue(aBSplineSurface2 is not None) | ||
| aBSplineSurface3 = aGeomFill3.Surface() | ||
| self.assertTrue(aBSplineSurface3 is not None) | ||
|
|
||
| def test_pipes(self): | ||
| """Test: pipes""" | ||
| a1 = [gp_Pnt(-4, 0, 2)] | ||
| a1.append(gp_Pnt(-5, 1, 0)) | ||
| a1.append(gp_Pnt(-6, 2, -2)) | ||
| a1.append(gp_Pnt(-5, 4, -7)) | ||
| a1.append(gp_Pnt(-3, 5, -12)) | ||
|
|
||
| xxx = point_list_to_TColgp_Array1OfPnt(a1) | ||
| SPL1 = GeomAPI_PointsToBSpline(xxx).Curve() | ||
|
|
||
| aPipe = GeomFill_Pipe(SPL1, True) | ||
| aPipe.Perform(False, False) | ||
| aSurface = aPipe.Surface() | ||
| self.assertIsNotNone(aSurface) | ||
|
|
||
| P = ICQ.Point(i) | ||
| assert isinstance(P, gp_Pnt) | ||
| # pstring = "P%i" % i |
There was a problem hiding this comment.
issue (code-quality): Avoid loops in tests. (no-loop-in-tests)
Explanation
Avoid complex code, like loops, in test functions.Google's software engineering guidelines says:
"Clear tests are trivially correct upon inspection"
To reach that avoid complex code in tests:
- loops
- conditionals
Some ways to fix this:
- Use parametrized tests to get rid of the loop.
- Move the complex logic into helpers.
- Move the complex part into pytest fixtures.
Complexity is most often introduced in the form of logic. Logic is defined via the imperative parts of programming languages such as operators, loops, and conditionals. When a piece of code contains logic, you need to do a bit of mental computation to determine its result instead of just reading it off of the screen. It doesn't take much logic to make a test more difficult to reason about.
Software Engineering at Google / Don't Put Logic in Tests
| for P in array: | ||
| i = i + 1 | ||
| make_vertex(P) |
There was a problem hiding this comment.
issue (code-quality): Avoid loops in tests. (no-loop-in-tests)
Explanation
Avoid complex code, like loops, in test functions.Google's software engineering guidelines says:
"Clear tests are trivially correct upon inspection"
To reach that avoid complex code in tests:
- loops
- conditionals
Some ways to fix this:
- Use parametrized tests to get rid of the loop.
- Move the complex logic into helpers.
- Move the complex part into pytest fixtures.
Complexity is most often introduced in the form of logic. Logic is defined via the imperative parts of programming languages such as operators, loops, and conditionals. When a piece of code contains logic, you need to do a bit of mental computation to determine its result instead of just reading it off of the screen. It doesn't take much logic to make a test more difficult to reason about.
Software Engineering at Google / Don't Put Logic in Tests
| for j in range(harray.Lower(), harray.Upper() + 1): | ||
| i = i + 1 | ||
| P = harray.Value(j) | ||
| make_vertex(P) |
There was a problem hiding this comment.
issue (code-quality): Avoid loops in tests. (no-loop-in-tests)
Explanation
Avoid complex code, like loops, in test functions.Google's software engineering guidelines says:
"Clear tests are trivially correct upon inspection"
To reach that avoid complex code in tests:
- loops
- conditionals
Some ways to fix this:
- Use parametrized tests to get rid of the loop.
- Move the complex logic into helpers.
- Move the complex part into pytest fixtures.
Complexity is most often introduced in the form of logic. Logic is defined via the imperative parts of programming languages such as operators, loops, and conditionals. When a piece of code contains logic, you need to do a bit of mental computation to determine its result instead of just reading it off of the screen. It doesn't take much logic to make a test more difficult to reason about.
Software Engineering at Google / Don't Put Logic in Tests
| for j in range(harray2.Lower(), harray2.Upper() + 1): | ||
| i = i + 1 | ||
| P = harray2.Value(j) | ||
| make_vertex(P) |
There was a problem hiding this comment.
issue (code-quality): Avoid loops in tests. (no-loop-in-tests)
Explanation
Avoid complex code, like loops, in test functions.Google's software engineering guidelines says:
"Clear tests are trivially correct upon inspection"
To reach that avoid complex code in tests:
- loops
- conditionals
Some ways to fix this:
- Use parametrized tests to get rid of the loop.
- Move the complex logic into helpers.
- Move the complex part into pytest fixtures.
Complexity is most often introduced in the form of logic. Logic is defined via the imperative parts of programming languages such as operators, loops, and conditionals. When a piece of code contains logic, you need to do a bit of mental computation to determine its result instead of just reading it off of the screen. It doesn't take much logic to make a test more difficult to reason about.
Software Engineering at Google / Don't Put Logic in Tests
test/test_core_geometry.py
Outdated
| if TR.IsDone(): | ||
| NbSol = TR.NbSolutions() | ||
| for k in range(1, NbSol + 1): | ||
| circ = TR.ThisSolution(k) | ||
| # find the solution circle | ||
| pnt1 = gp_Pnt2d() | ||
| parsol, pararg = TR.Tangency1(k, pnt1) | ||
| assert parsol > 0.0 | ||
| assert pararg > 0.0 | ||
| # find the first tangent point | ||
| pnt2 = gp_Pnt2d() | ||
| parsol, pararg = TR.Tangency2(k, pnt2) | ||
| assert parsol > 0.0 | ||
| assert pararg > 0.0 | ||
| # find the second tangent point |
There was a problem hiding this comment.
issue (code-quality): Avoid conditionals in tests. (no-conditionals-in-tests)
Explanation
Avoid complex code, like conditionals, in test functions.Google's software engineering guidelines says:
"Clear tests are trivially correct upon inspection"
To reach that avoid complex code in tests:
- loops
- conditionals
Some ways to fix this:
- Use parametrized tests to get rid of the loop.
- Move the complex logic into helpers.
- Move the complex part into pytest fixtures.
Complexity is most often introduced in the form of logic. Logic is defined via the imperative parts of programming languages such as operators, loops, and conditionals. When a piece of code contains logic, you need to do a bit of mental computation to determine its result instead of just reading it off of the screen. It doesn't take much logic to make a test more difficult to reason about.
Software Engineering at Google / Don't Put Logic in Tests
No description provided.