Betty unit test.

[ghost]

Add OS executor test suite.

[ghost]

Add DateTime executor unit test.

[igorrKurr]

I think that it is not very good approach when you add functionality just to make test pass. I've implemented my vision of module test in #101 . I think it's a little better than that version because it allows strictly check if module methods was correct.

[ghost]

1. OS executor test suite. Update: Change the way it tests the specified module functionality as suggested by Jeff Pickhardt. Now the test suite is more robust.

[ghost]

2. DateTime executor test suite. Update: Change the way it tests the specified module functionality as suggested by Jeff Pickhardt. Now the test suite is more robust.

[ghost]

3. Count executor test suite.

[ghost]

4. Find executor test suite.

[ghost]

I think that it is not very good approach when you add functionality just to make test pass. I've implemented my vision of module test in #101 . I think it's a little better than that version because it allows strictly check if module methods was correct

Nope. The purpose of these test suites are not checking the correctness of specified module methods. The correct purpose is to see that does the specified module return our preferred command or not?

[ghost]

5. Internet executor test suite.

[ghost]

@pickhardt need you to participate here. @pannous need you to participate here.

[igorrKurr]

The correct purpose is to see that does the specified module return our preferred command or not?

Yes, but you've said what I mean.In your new tests you've checked functionality.But in previous version you've not.So my comment was about that.Now your tests seem to be ok.

Nope. The purpose of these test suites are not checking the correctness of specified module methods.

You test module here.So as much aspects you'd test as better your test suite is.I understand that you can't write test on help methods, but all other methods module functionality depends on are better to cover.Maybe not now, but it is good practice when your test coverage is high.

[pickhardt]

The new tests you wrote are pretty good, @Ch0c0late. @igorrKurr's approach to testing is better because he tests the actual command response, and because he doesn't add functionality to the actual code just for the purposes of testing.

I can't automatically merge this pull request due to merge conflicts. Probably because I just merged this one https://github.com/pickhardt/betty/pull/101/files Can you fix the merge conflicts?

[ghost]

@pickhardt Should I merge the upstream change(those the @igorrKurr wrote) into this branch?

[pickhardt]

Yeah, you'll have to merge the current dev into your branch.

Sent from my Android. On May 20, 2014 11:10 PM, "Muhammad Hussein Nasrollahpour" < [email protected]> wrote:

@pickhardt https://github.com/pickhardt Should I merge the upstream change(those the @igorrKurr https://github.com/igorrKurr wrote) into this branch?

Reply to this email directly or view it on GitHubhttps://github.com/pickhardt/betty/pull/88#issuecomment-43715580 .

[ghost]

@pickhardt Thanks. I'm going to merge it.

[ghost]

@pickhardt Merged dev into betty unit-test branch. Hope it works correctly.

[ghost]

@pickhardt Wrote test for all of betty's modules.

[brysgo]

These integration tests look great!

In terms of test style, can I get someone to look at #129

[ghost]

@brysgo Took a look at it. Looks good.

[brysgo]

Getting these tests in is high priority for me. I'm going to merge in my fun tests and we can use the test configuration from it here.

[brysgo]

If you rebase this off the current dev branch, you can run bundle then rake to run the tests.