5 ms·

> So yeah, assuming this was for part of an existing system where I'd already tested generic facilities like database access and JSON serialization, I wouldn't

> So yeah, assuming this was for part of an existing system where I'd already tested generic facilities like database access and JSON serialization, I wouldn't feel the need to write this test at all. But this is the generic facility for database access. This is just an additional special case it has to handle. Does that change your perspective on whether you would write a test for it? > That aside, what pieces could actually go wrong in a statically typed language? Well, I could type the SQL wrong, but let's assume we are working in a sufficiently awesome statically typed language that would catch that kind of error. I could filter on the wrong column, with the wrong operator, with the wrong value, on the wrong table. I could decode the name column using the wrong encoding. I could return multiple rows per option. I could do a huge number of other things that I couldn't think of. These may not be really likely to be mistakes I'd make (this is a pretty simple task), but several refactorings down the line, I can easily see an issue being introduced. At the end of the day, even in a statically typed language where much of the functionality would be verified by the compiler, I'd still like to have a test on this. > Ok, good example on some levels, though it's doing a lot of interfacing with untyped parts Hmm... the fact that it deals with the boundary of the system and the fact that it deals only with converting data from one format to another might render it a poor sample (i.e. there's not really much interesting logic). I can come up with another if you are interested.

lmm 10y ago
> But this is the generic facility for database access. This is just an additional special case it has to handle. Presumably it would be using a lower layer - or more likely an existing library - for doing the actual query though? > I could filter on the wrong column, Not if you've got a typed representation of which column's which > with the wrong operator, Not if equality is the only operator available. This is one of my biggest reasons for using wrapper types around IDs - you shouldn't treat IDs as integers, because the idea of adding or multiplying or <=ing an ID makes no sense. > with the wrong value, How? You have to use the passed ID for something, and it can't do anything else. > on the wrong table. So make the table part of the type. A list ID is a different thing from a user ID, they shouldn't be compatible. > I could decode the name column using the wrong encoding. Encoding should absolutely be handled with types. > I could return multiple rows per option. Hmm, maybe. But I can't see how you'd do that by accident. > At the end of the day, even in a statically typed language where much of the functionality would be verified by the compiler, I'd still like to have a test on this. I started out thinking the same thing (I moved from Java/Python to Scala). I've gradually reduced the amount of tests I write over four years as I've found them to not add value. I was as surprised as anyone, and even privately entertained the thought that maybe I was some kind of super-programmer who was smarter than all those people who needed tests, but that month or two of trying to do stuff in Django made it very clear that it wasn't me, it was the language. > Hmm... the fact that it deals with the boundary of the system and the fact that it deals only with converting data from one format to another might render it a poor sample (i.e. there's not really much interesting logic). I can come up with another if you are interested. Yeah, happy to if you're interested. It's a useful exercise in thinking it through for myself as much as anything.
- winstonewert 10y ago
  > I started out thinking the same thing (I moved from Java/Python to Scala). Ah, Scala. I could be prepared to believe that this is true for Scala (and similarly advanced typed systems). It is when people claim they write fewer tests in java than in python that I found it really dubious. > Yeah, happy to if you're interested. It's a useful exercise in thinking it through for myself as much as anything. Ok here's another test: These are action objects, they represent a sequence of user actions on a JobExtra. const actions = [ JobExtra.actions.load(undefined), JobExtra.actions.field('changeAmount', Money.actions.set(new Decimal("12.45"))), JobExtra.actions.field('certifiedForemanRelated', Checkbox.actions.set(true)), JobExtra.actions.field('appliedPercentage', Percentage.actions.set(new Decimal("4.5"))) ] I construct the final state by reducing across all those actions const state = _.reduce(actions, (state, action) => JobExtra.reducer(state, action), undefined) I verify that the job extra is considered valid afterwards. strictEqual(true, isJobExtraValid(state)) To be considered valid: 1. The changeAmount must be set to non-zero 2. The certifiedFormanRelated must be false or the appliedPercentage must be true But, if the user modifies the appliedPercentage, the certifiedFormanRelated should be automatically set to true. So this, and a number of related tests verify that under different sequences of actions I end up the result I expected. Is there a way to push this into the type system?
  - lmm 10y ago
    Yep. Ensuring something is valid is a great fit for use of types - you make sure that the type is inherently valid and it's impossible to construct in an invalid state. For 1., you could have a non-zero number type, or you could settle for a check in the JobExtra constructor. For 2., it sounds like this is a coproduct situation - a JobExtra is either certifiedFormanRelated or has an appliedPercentage. Scala doesn't quite have native support for coproducts the way it does for tuples, but you could represent it with a sealed class hierarchy: sealed trait ForemanOrPercentage case class ForemanRelated() extends ForemanOrPercentage case class AppliedPercentage(value: Decimal) extends ForemanOrPercentage or being a bit lazier you could just use an Option[Decimal] and say that if it's Some it's the applied percentage and if it's None then it's certified foreman related. In Java there isn't a "sealed" keyword, but you can emulate it with the visitor pattern - you'd define a ForemanOrPercentageVisitor and only ever operate on ForemanOrPercentages via the visitor. That way if someone creates their own subtype of ForemanOrPercentage it still has to behave like one or the other, because they still have to implement visit().

lmm 10y ago

> But this is the generic facility for database access. This is just an additional special case it has to handle. Presumably it would be using a lower layer - or more likely an existing library - for doing the actual query though? > I could filter on the wrong column, Not if you've got a typed representation of which column's which > with the wrong operator, Not if equality is the only operator available. This is one of my biggest reasons for using wrapper types around IDs - you shouldn't treat IDs as integers, because the idea of adding or multiplying or <=ing an ID makes no sense. > with the wrong value, How? You have to use the passed ID for something, and it can't do anything else. > on the wrong table. So make the table part of the type. A list ID is a different thing from a user ID, they shouldn't be compatible. > I could decode the name column using the wrong encoding. Encoding should absolutely be handled with types. > I could return multiple rows per option. Hmm, maybe. But I can't see how you'd do that by accident. > At the end of the day, even in a statically typed language where much of the functionality would be verified by the compiler, I'd still like to have a test on this. I started out thinking the same thing (I moved from Java/Python to Scala). I've gradually reduced the amount of tests I write over four years as I've found them to not add value. I was as surprised as anyone, and even privately entertained the thought that maybe I was some kind of super-programmer who was smarter than all those people who needed tests, but that month or two of trying to do stuff in Django made it very clear that it wasn't me, it was the language. > Hmm... the fact that it deals with the boundary of the system and the fact that it deals only with converting data from one format to another might render it a poor sample (i.e. there's not really much interesting logic). I can come up with another if you are interested. Yeah, happy to if you're interested. It's a useful exercise in thinking it through for myself as much as anything.

winstonewert 10y ago
> I started out thinking the same thing (I moved from Java/Python to Scala). Ah, Scala. I could be prepared to believe that this is true for Scala (and similarly advanced typed systems). It is when people claim they write fewer tests in java than in python that I found it really dubious. > Yeah, happy to if you're interested. It's a useful exercise in thinking it through for myself as much as anything. Ok here's another test: These are action objects, they represent a sequence of user actions on a JobExtra. const actions = [ JobExtra.actions.load(undefined), JobExtra.actions.field('changeAmount', Money.actions.set(new Decimal("12.45"))), JobExtra.actions.field('certifiedForemanRelated', Checkbox.actions.set(true)), JobExtra.actions.field('appliedPercentage', Percentage.actions.set(new Decimal("4.5"))) ] I construct the final state by reducing across all those actions const state = _.reduce(actions, (state, action) => JobExtra.reducer(state, action), undefined) I verify that the job extra is considered valid afterwards. strictEqual(true, isJobExtraValid(state)) To be considered valid: 1. The changeAmount must be set to non-zero 2. The certifiedFormanRelated must be false or the appliedPercentage must be true But, if the user modifies the appliedPercentage, the certifiedFormanRelated should be automatically set to true. So this, and a number of related tests verify that under different sequences of actions I end up the result I expected. Is there a way to push this into the type system?
- lmm 10y ago
  Yep. Ensuring something is valid is a great fit for use of types - you make sure that the type is inherently valid and it's impossible to construct in an invalid state. For 1., you could have a non-zero number type, or you could settle for a check in the JobExtra constructor. For 2., it sounds like this is a coproduct situation - a JobExtra is either certifiedFormanRelated or has an appliedPercentage. Scala doesn't quite have native support for coproducts the way it does for tuples, but you could represent it with a sealed class hierarchy: sealed trait ForemanOrPercentage case class ForemanRelated() extends ForemanOrPercentage case class AppliedPercentage(value: Decimal) extends ForemanOrPercentage or being a bit lazier you could just use an Option[Decimal] and say that if it's Some it's the applied percentage and if it's None then it's certified foreman related. In Java there isn't a "sealed" keyword, but you can emulate it with the visitor pattern - you'd define a ForemanOrPercentageVisitor and only ever operate on ForemanOrPercentages via the visitor. That way if someone creates their own subtype of ForemanOrPercentage it still has to behave like one or the other, because they still have to implement visit().