Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Class that prepopulates database for tests #9

Open
BinaryIgor opened this issue Dec 15, 2018 · 5 comments
Open

Class that prepopulates database for tests #9

BinaryIgor opened this issue Dec 15, 2018 · 5 comments

Comments

@BinaryIgor
Copy link

BinaryIgor commented Dec 15, 2018

I find it very difficult to test classes from com.github.fabriciofx.cactoos.jdbc.rset, because real data in database is required. In SelectTest.select() there is a code that can be used for that purpose. How about moving it to object that will make possible to reuse it?

@fabriciofx
Copy link
Owner

@Iprogrammerr Hi Igor! That's a good idea, but won't break this rule?

@mdbs99
Copy link

mdbs99 commented Dec 17, 2018

@fabriciofx the rule "Test Methods Must Share Nothing" is not 100% right, IMHO. You can share data/code among the tests, but you cannot do this in a specific order like "method A should run before B, then C".
Another thing is: if you share data among tests, you need to guarantee that the data should came back to its initial state before use it in another test.

@fabriciofx
Copy link
Owner

@mdbs99 Thanks for sharing your knowledge with us! But when you're saying "method A should run before B, then C" and "if you share data among tests, you need to guarantee that the data should came back to its initial state before use it in another test." there isn't a conflict between them, because I should use setup() and teardown() methods to achieve it?

@mdbs99
Copy link

mdbs99 commented Dec 17, 2018

If there is not conflict (eg. the data is readonly, it's always in the same state), you don't need to use setup() and teardown().

@BinaryIgor
Copy link
Author

@fabriciofx In this case table/tables with some records is precondition for testing classes from specific package(rset in this case). So this rule does not apply here. Moreover, we can make this class configurable so if will prepopulate databse with table that can be defined dynamically, so that our test will not depend on some specific table.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants