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

Add @idata(iterable) decorator-function. #40

Merged
merged 1 commit into from
Sep 10, 2016

Conversation

ankostis
Copy link
Contributor

The purpose is to replace the construct below:

@data(*[a for a in foo if a > 0])

With this typing & memory-efficient alternative:

@data(a for a in foo if a > 0)

(*) It is a minor change that should not interfere with the possible re-write of the library in other branches.

@ankostis
Copy link
Contributor Author

The flake8 fails in the TC class is unrelated to my modifications to the code.

@codecov-io
Copy link

codecov-io commented May 29, 2016

Current coverage is 100% (diff: 100%)

Merging #40 into master will not change coverage

@@           master   #40   diff @@
===================================
  Files           1     1          
  Lines         104   106     +2   
  Methods         0     0          
  Messages        0     0          
  Branches        0     0          
===================================
+ Hits          104   106     +2   
  Misses          0     0          
  Partials        0     0          

Powered by Codecov. Last update 2d0a689...347fe29

@txels
Copy link
Collaborator

txels commented May 29, 2016

Sorry, this fell off my radar.
Looks good. The flake8 issue is solved in master, so a rebase would fix it.

I'd love to see some test and documentation.

@pradyunsg
Copy link
Contributor

pradyunsg commented May 31, 2016

May I take charge of this PR and submit a new PR the same feature with tests and documentation?

@ankostis
Copy link
Contributor Author

Of course!

@txels
Copy link
Collaborator

txels commented Aug 4, 2016

BTW in terms of memory efficiency: since ddt is not (nor wants to be) a test runner, in order for the test runner to work properly it has to make the class look like it has one different test method per data value - these extra methods are created dynamically at class load time, not at test execution time. Meaning that the whole generator data will have to be materialised in memory anyway, hence there will not be the typical memory savings of other scenarios where generators are used.

If you need to test with large datasets, ddt is not going to be a memory efficient approach.

@txels
Copy link
Collaborator

txels commented Aug 5, 2016

@ankostis FYI this is my current thinking about where to take this library, that use iterable test data as the base concept #44 (comment)

The purpose is to avoid:: 

  @DaTa(*[a for a in foo if a > 0])
@ankostis
Copy link
Contributor Author

ankostis commented Aug 7, 2016

@txels rebased, and all tests pass, as promised.
Thanks for the explanation of the no-memory-gains for this PR,
so we are only left with the typing gains :-)

@txels txels merged commit 969c915 into datadriventests:master Sep 10, 2016
@txels
Copy link
Collaborator

txels commented Oct 7, 2016

Released in 1.1.1

Sorry about the delay in releasing.

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

Successfully merging this pull request may close these issues.

4 participants