How to validate if ternary operator was used in the implementation?

Question

I want to validate through the TDD if in the implementation was applied ternary operators.

How can I measure this situation?

def par_impar(x):
   return "impar" if x % 2 else "par"

Or this other?

par_impar = lambda x: "impar" if x % 2 else "par"

Goal:

Through TDD - Test Driven Development (Directed/Test Driven Development), it aims to outline the development according to the project requirements. And the developer will use his experience to serve them. As this will be training I want to force some implementations to be applied.

Answer 1

TDD is not that

TDD is not what you seem to believe it to be. It is a development methodology used to better understand the problem and formally specify how the code should result in.

It happens more or less like what happened with OOP, people think it’s a mechanism, but it’s a technique to build a better system. The goal of OOP is not to build objects but to build coherent modeling. The goal of TDD is not to test something but to model something that makes sense. As OOP did not deliver what they promised now they would try one more technique, who did not deliver what they promised and go get another (DDD? that also does not deliver), who knows one day understand that there is no technique that does this, it is construction of general knowledge that generates a better model.

The basic way to do this is to build a test that correctly indicates the result, that is, you specify what will have to be done in a simple way and afterward will build a code that gives the outworking.

By the time you wrote the code that will accomplish something already finished the chance to apply the TDD.

Plus, just like a lot with OOP, people think they can learn this from artificial exercises. Can’t, this form just teaches wrong.

So the question starts from a wrong premise. It does not have the requirement, it does not have a clear and detailed description of the problem to write the test that would be the implementation of TDD. So even if the code to be executed did not yet exist, there would be no way to write the TDD.

One of the criticisms I always make of TDD is that it does not solve anything when the person does not know how to specify well. It’s just a way to write the specification, it doesn’t make the specification good and correct. And many people believe that doing TDD your application will be correct. TDD is just like choosing to use typewriter instead of pen to write the specification, this has there some advantage but does not solve the real problem, and has disadvantage too.

But trying to infer what the problem is by the written code, and I repeat, this is not TDD, you would have to write code that checks whether it always responds correctly to some data entries, even if the correct one is wrong, because the best tests are the ones that send an input that should produce a problem and understand how the code behaves.

How should TDD be

In this case it makes sense to call this function by passing as argument some numbers, for example 0, some small positives in sequence, including even and odd numbers, prime numbers, negative numbers, very large numbers (in Python it is not necessary to check capacity overflow of specific numeric type because it handles it alone). You would need to test with values that are not numbers, such as boolean or string, or objects in general, none of these entries should be accepted.

The test has to check if the return of the function is what it expects or if it throws some error, when this is expected.

Python has a module that already helps deal with all this. There are several external libraries (example) that help the process and some more sophisticated, but the TDD itself can be used with any of them, even the simplest or even with nothing additional. And has book on.

A simple example to test your code (see the documentation for all usage details and don’t consider this as the best code for the case):

def teste_par_impar(self):
    self.assertEqual(par_impar(0), "par")
    self.assertEqual(par_impar(1), "impar")
    self.assertEqual(par_impar(2), "par")
    self.assertEqual(par_impar(-1), "impar")
    self.assertEqual(par_impar(-2), "par")
    self.assertEqual(par_impar(9999999999999999999999999999), "impar")
    self.assertEqual(par_impar(-2), "par")
    self.assertRaises(Exception, par_impar("1"))

I put in the Github for future reference.

I would have to test more things, so I always say that people are naive when they create tests and they do it, usually by fashion, to pretend that they’re doing it right because everyone is saying that this is the only way it’s right.

This is a case that shows how people tend to test what’s too easy and doesn’t have much to go wrong, and in general they don’t test well exactly what can go wrong (my experience that especially in TDD people usually ignore this part, which is the most important, and after that gives problem she goes adding more useful tests, which plays the TDD by land). And it’s common for people to leave the most important tests there because it’s a lot of work, she can’t do it right, or even when she does it doesn’t get good, full of holes and ends up giving only a false sense of security, until she gives up (If you don’t learn to do it right, there are people who do it, but it’s very rare).

TDD does not verify implementation

TDD is not one to validate anything. It makes less sense to even try to apply the technique by looking at the implementation. What does it matter if you are using a conditional operator (which is ternary, but this is not its function, ternary is a different and secondary attribute of the operator), could be using something else, could change and the test should not have to be changed because of this. Neither TDD, nor unit test, nor anything similar aims to verify if the implementation is right, the purpose of these techniques is to verify if the established contract produces the right result.

The TDD cannot be used to verify that the implementation is in agreement with anything, only if the result is. There is a technique for this, but it is not very widespread because it is usually a mistake to worry about this.

Developing software is not coding

One of the things that I always talk about here and a lot of people don’t care about is that if you can’t ask a proper question here, it’s because you’re not ready to develop software. It can even produce code, but not develop software. Developing software involves a lot and goes beyond mastering the syntax of the language and the basics of the tools that are used in the process. It is necessary to understand the problem, in the right way, it is necessary to conceptualize right, to model properly. You need to have an understanding of a text that doesn’t even exist yet, so you need to produce a suitable text, according to the problem presented, that shows the reality. Very rare who can do this.

Some think this is academicism or even elitism, but there’s no other way to do it right. Either the person solves this question or he can’t do it right. It only makes TDD right who can understand and express the problem correctly. It’s not the mechanism that matters, if you know how to do it right the mechanism can be anyone, it can be some more abstract.