Hot answers tagged

8

Seems OK to me. However, it might be nice to add a "macro" to let you skip the I18n. and just use t like you do in views. And you can add some extra checks while you're at it, since you'll i18n want it to make noise when testing. For instance, you could add a file like spec/support/macros/i18n_macros.rb with the following: module I18nMacros def t(*args)...


7

You are asking about your tests but there are issues in your code that should be addressed before you start testing. public abstract class Product { public abstract bool Check(Customer customer); } You made Product an abstract class but this is not necessary. It does not provide any default implementation for anything so an simple interface would be ...


5

This is roughly what BDD should look like. You're definitely on the right track in that you have a specific set of postconditions and expected results for every "public" method. However, the tests for these postconditions are incomplete in some respects that I think will probably come up as edge conditions and/or browser quirks (assuming your system is ...


5

I am specifically trying to follow the principle of least astonishment this and that public IList<IProduct> _assignedProducts = new List<IProduct>(); don't get along well. A public field with an _ underscore? I'm more then surprised ;-) But not only by that. If I can access this field directly, there is actually no need for me to want to use ...


3

One of the hardest piece of knowledge to learn as a developer is: code duplication does not mean responsibility duplication. Having said this, you are testing different methods so it's ok to have more than one test. In this case, you are testing complementary (or were they supplementary? I never remember it) methods, so to test one, you need to have the ...


3

public abstract class ContextSpecification { protected ContextSpecification() { Context(); BecauseOf(); } protected virtual void BecauseOf() { } protected virtual void Context() { } protected virtual void Cleanup() { } } This class does a few things wrong: The constructor seems to call methods that go beyond a ...


3

Handling invalid input Instead of returning an array when inputs are invalid, throw exceptions and use throw to detect it in the tests. Avoid else when previous blocks have return statements The else can be eliminated since the block evaluated when value <= 0 has a return statement (or would throw an exception). Additionally, the switch statement can be ...


2

Your problem seems to arise due to the fact, that your project is build from only one class (= unit). With acceptance tests you test a non-programmers view of your project, that is whether it fullfills given requirements. Acceptance tests are formulated in a style of someone who actually uses features of your program and has no insights on what is going on ...


2

Let me say up front that I'm far more familiar with unit testing than behavior testing, but this looks an awful like you wrote the tests after the code. When I think of "behavior", I don't think of neatly mapping it to method names. Instead I would write use cases that may require multiple method calls. Note: I don't recall seeing nested describe blocks ...


2

My suggestions would be: Create a helper for common sign up and sign in logic: # E.g. spec/support/helpers/session_helpers.rb module Features module SessionHelpers def sign_up_with(email, password, confirmation) visit new_user_registration_path fill_in 'Email', with: email fill_in 'Password', with: password fill_in 'Password ...


2

In my opinion, if you think that each test has a different meaning, there is nothing wrong with them. What you can do to extract the duplication is to have a dedicated method to arrange your test. But in this case there will be no real gain.


1

Sloppy left hand formatting in general public class Concor : IProduct { private const decimal _expenditure = 100; private const string _gender = "F"; public bool IsEligible(Customer customer) { if (customer.Expenditure < _expenditure) { return true; } else { return false; ...


1

Overall You only have a few cases where you validate data passed to your class setters. Generally, it is a good idea to type hint and/or validate (when type hinting can not be performed) all values passed to public class methods before working with them in your classes. I would strongly suggest you get in the habit of using strict comparisons (===, !==) as ...


Only top voted, non community-wiki answers of a minimum length are eligible