在我们进入本章的重要部分之前，我们给出了一个警告，正如jav a，groovy允许进行 Boo lean测试的表达式被指定给变量，不像java，Boo lean测试的类型没有被严格的限制为 boolean，这意味着你也许再现著名的历史问题，尽管更人性化，也就是说，“==”等号操作符与赋值操作符“=”是一个彻底不同的有效代码。
Groovy无法避免这个经常出现的陷阱： 在if语句中作为顶级表达式使用的时候。不管怎样，这仍旧出现的比较少。
列表6.2 显示了这个主题的典型变化
在（1）的相等比较是良好的并且在java中也是允许的，在（2），这个相等比较是有意的，但是只有一个等号，这将导致groovy编译错误，因为在if语句中的顶级表达式不能是一个赋值表达式。
不管怎样，Boolean测试能够被嵌套在任何深度的表达式中，最简单的如（3）所示，这里有额外的圆括号将赋值语句包围起来，使得赋值语句成为了一个子表达式，这样这个语句符合了groovy的语言规范，在这里，值3分配给变量x，然后x将被用来进行测试，由于3被任务为true，因此值3将被打印出来，这个圆括号的使用欺骗了编译器，这样可以节省了赋值的一行代码，出现额外的圆括号是罕见的，因此这里做了一个警告读者的角色。
赋值表达式被限制不能作为if语句的顶级表达式，但是对于其他的控制结构语句（如 while）没有这个限制，这是由于赋值和测试在一个表达式经常被用在w hile中，如4），这种风格的典型用法是从转换器中接收处理标记或者从流中读取数据。虽然这是便利的，但这也容易让我们犯如（5）所示的错误，这里为x分配了一个值1，如果没有 reak语句，将形成一个死循环。
这种潜在的bug在别的语言也存在（如C和C++也存在这种问题），在你希望进行比较的时候在等号的左边放置常量，这样上表中最后一个 while语句变为：
这样将产生一个错误，你不能给一个常量赋值，这样是安全的，遗憾的是，比较的两边都是变量也会失败，这也降低了可读性，不管人类语言的自然习惯，还是条件，大多数人们发现w hile(x==3)读起来比w hile(3==x)更加简单。
虽然两者都不会引起混淆，后者更容易打断人们的思路。
在这本书，我们优先考虑可读性，但是我们的情况与一般的开发稍微有点不同，你必须自己决定使用哪种习惯对你来说更好。
现在我们已经讨论了在groovy中哪种表达式被认为是true，哪种表达式被认为是false，现在我们可以开始看看控制结构了。